Exhibit 5 



Prom: manser [manser@charybdis] 

Sent: Wednesday, August 16, 1995 4:12 PM 

To: craig; hayes 

Subject: RE: Zeus summary/Friday 8/12/95 

Ray/Craig, 



Do we have an understanding of cache misses vs cache size - per the below' 
Or are the misses outside of (fast) cache into (slow) memory? 



Steve 



From: Graham Y. Mostyn on Tue, Aug 15, 1995 1:05 PM " ' 

Subject: Zeus summary/Friday 8/12/95 
To: zeus 

Cc: graham; mouss 

Minutes of the Zeus summary meeting, reporting the activities of the technology 
architecture and marketing sub-groups. ^ y ' 

Friday 8/12/95 

Attendees: bill gmo graham hayes tbr todd 
TECHNOLOGY GROUP 

* Bill presented Zeus die cost data as a function of logic nets and memory size. 

He had. studied the relationship between the number of logic nets, the total and average 

He'no^h 5 ; T £ ^ aV ^ labl V S - aCtUal USSd f ° r Wirin * ° n Euter P e and "nemo- 

He noted that for both chips, the measure of routing efficiency (available/actual wiring 
area) was similar; 1.8 and 2.2 respectively. wiring 

Based on the assumption that Zeus, like Euterpe and Mnemo, would also be wire-limited, he 
?f° 3 ^ t ® d l° gX ^ area a f a f action of net number, taking the cases where the average wire 
length is fixed, and where the average wire length is proportional to the net number. 

Adding area for memory size and pads, he applied Murphy yield calculations and 
representative 8 inch CMOS wafer costs to compute die cost. 

* Bill also presented costs attributable to cooling. 

cos? of t ?he t supply t iisel?) ld regU±red for the chi P and *> ower "ipply (but not the 

This suggested bounds of 30c to 50c per watt over the range 15W to 120W. 

algorithm^' PUrSUS P acka 9 e costs - We then have a quite complete cost-analysis 

ARCHITECTURE GROUP 

booting^Six 1 " 61 " at laSt meet±n9 was to ^erstand the low utilization of a cylinder in 



He concluded that the compiler could not contribute to the problem very much, other than 
s?al?r 9 1SSUe restrlctions " not ver y significant, compared to D and I cache initiated 

wir 2 fmLSonlnstruc3on:. in EUterPe ' S 50 "tails are associated 

'From last week-s minutes, of the 50M, issue restrictions account for ~7M while cache 
iisses account for ~33M) . 
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* Tim pointed out that the current Euterpe multithreaded architecture has high cache 
penalties, but offers guaranteed throughput, important when interaction must occur between 
threads. 

He asked what should our metric be for Zeus, a different architecture? Instructions per 
cycle? We agreed that the benchmark will be clearer when we have isolated the main 
applications of interest. 

MARKETING GROUP 

Todd reported on the group's activities of the past week. 

* He had studied our competitors' activities from Microprocessor report and the Web. He 
noted that their publicized business plans were remarkably similar to purs, based upon 
addressing multimedia applications by adding DSP capability to their processors. 

Philips, for example, is developing a new processor core with VLIW architecture; 
specialized operations are being added for video compression and communications. He felt, 
in particular, that Intel could pose a threat by adding DSP functions slowly, step by 
step. He had also examined DEC, IBM and Intel. 

He pointed out that MicroUnity has the benefit of not being constrained by needing to 
include support for existing customers in new product offerings, however. 

* He emphasized the importance of selecting markets and developing an entry strategy for 
each; why would customers need the technology? The benefits must be apparent. 

* Next step: 

- Having already considered the PC, cablemodem and set top platforms, the group is 
analysing the attractiveness of additional platforms/applications, in particular, 
networking and communications. " V 

- They will also present a summary of competitive microprocessor performance/ cost, 
alongside Zeus cost data obtained from the technology group. 



End Included Message 



End Included Message 
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From: 



jack (Jack Wenstrand) 

Wednesday, August 16, 1995 2:30 PM 

zeus 

tony 

Re: Zeus summary/Friday 8/.12/95 



Sent: 
To: 
Cc: 



Subject: 



> Date: Tue, 15 Aug 1995 13:02:23 -0700 

> From: graham (Graham Y. Mostyn) 

> Minutes of the Zeus summary meeting, reporting the activities of the 

> technology, architecture and marketing sub-groups. 

> Friday 8/12/95 
* * * 

> ARCHITECTURE GROUP 

> * Tim pointed out that the current Euterpe multi-threaded architecture 

> has high cache penalties, but offers guaranteed throughput, important 

> when interaction must occur between threads. 

Monica Lam of Stanford present work at Hot Chips on "Hot compilers for hot chips" to 
address the the question "Are multiprocessors competitive to processors with high 
instruction- level parallelism?". In support of Tim's point, she emphasized that that 
performance improvements super- linear with processor count were readily achieved with 
multiple processors where coarse-grained parallelism was found because of additional 
cache, but that little speed-up could be achieved with multiple processors where fine- 
grained communication between threads was required. She mentioned the advantages of 
multi- threaded architectures for this class of applications. 



> He asked what should our metric be for Zeus, a different architecture? 

> Instructions per cycle? We agreed that the benchmark will be clearer 

> when we have isolated the main applications of interest . 



IPC, power, area, and clock all count... Also from Hot Chips, PowerPC presented a metric 



SPECint92 



Power (W) * Size(mm2) 
Coincidently, the PPC 603el66 was at the top of the chart by this metric. 

I've passed on some scaling and cost information presented by Gordon Moore to Bill Hemdon 
for the Technology group. 



- Jack 
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From: 



graham (Graham Y. Mostyn) 
Tuesday, August 15, 1995 3:02 PM 
zeus 

graham; mouss 

Zeus summary/Friday 8/12/95 



Sent: 

To: 

Cc: 



Subject: 



Minutes of the Zeus summary meeting, reporting the activities of the technology, 
architecture and marketing sub-groups. 
Friday 8/12/95 

Attendees: bill gmo graham hayes tbr todd 
TECHNOLOGY GROUP 

* Bill presented Zeus die cost data as a function of logic nets and memory size. 

He had studied the relationship between the number of logic nets, the total and average 
wire lengths, and the available vs. actual area used for wiring on Euterpe and Mnemo. 
He noted that for both chips, the measure of routing efficiency (available/actual' wiring 
area) was similar; 1.8 and 2.2 respectively. 

Based on the assumption that Zeus, like Euterpe and Mnemo, would also be wire-limited, he 
projected logic area as a function of net number, taking the cases where the average wire 
length is fixed, and where the average wire length is proportional to the net number. 

Adding area for memory size and pads, he applied Murphy yield calculations and 
representative 8 inch CMOS wafer costs to compute die cost. 

* Bill also presented costs attributable to cooling. 

He plotted the heatsink and fan costs required for the chip and power supply (but not the ( 
cost of the supply itself). 

This suggested bounds of 30c to 50c per watt over the range 15W to 120W. 

* Next step: Pursue package costs. We will then have a quite complete cost-analysis 
algorithm. 

ARCHITECTURE GROUP 

The action item at the last meeting was to understand the low utilization of a cylinder in 
booting Unix. 

* Ray Hayes presented his work on investigating how the compiler could reduce the number 
of stalls. 

He concluded that the compiler could not contribute to the problem very much, other than 
reducing issue restrictions - not very significant, compared to D and I cache initiated 
stalls. 

2 out of 3 cycles are stalls in Euterpe's architecture; 50 million stalls are associated 
with 21 million instructions. 

(From last week's minutes, of the 50M, issue restrictions account for ~7M, while cache 
misses account for ~33M) . 

* Tim pointed out that the current Euterpe multithreaded architecture has high cache 
penalties, but offers guaranteed throughput, important when interaction must occur between 
threads . 

He asked what should our metric be for Zeus, a different architecture? Instructions per 
cycle? We agreed that the benchmark will be clearer when we have isolated the main 
applications of interest. 

MARKETING GROUP 

Todd reported on the group's activities of the past week. 
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* He had studied our competitors' activities from Microprocessor report and the Web. He 
noted that their publicized business plans were remarkably similar to ours, based upon 
addressing multimedia applications by adding DSP capability to their processors. 

Philips,' for example, is developing a new processor core with VLIW architecture; 
specialized operations are being added for video compression and communications. He felt, 
in particular, that Intel could pose a threat by adding DSP functions slowly, step by 
step. He had also examined DEC, IBM and Intel. 

He pointed out that MicroUnity has the benefit of not. being constrained by needing to 
include support for existing customers in new product offerings, however. 

* He emphasized the importance of selecting markets and developing an entry strategy for 
each; why would customers need the technology? The benefits must be apparent. 

* Next step: 

- Having already considered the PC, cablemodem and set top platforms, the group is 
analysing the attractiveness of additional platforms/applications, in particular, 
networking and communications. 

- They will also present a summary of competitive microprocessor performance/cost, 
alongside Zeus cost data obtained from the technology group. 



End Included Message • 



End Included Message 
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Prom: hopper (Mark Hofmann) 

Sent: Tuesday, August 15, 1995 8:01 AM 

To: fl t {m ^ y? me ™ s J- E e * rt {Geert Ross eel); paulp (Paul Poenisch); anh (Anh Ngo); jack (Jack 

Wenstrand); nch (Rich McCauley); ong (Warren R. Ong); mouss (John MoussourisV tony 
(Tony Stelliga); manser (Steve Manser); drew; mudge (John mudge); cadettes- fung (Funq 
Chen); kumar; tomb; yao (Henry Yao); rip (Rajiv Patel); to (To Do); ted (Ted Chen)- ky (K Y " 
anderson am): '' an9: h °° V (Bi " Hooven); trancy ( Tranc y Tsao ): lind en (Linden Critch'low); 

Cc: f |y e u s (Maria Alves); graham (Graham Y. Mostyn); dane (Dane Snow); yves (Jean-Yves 
Michel); ras (Bob Sutherland); tomho (Tom Ho); michael (Chris Michael); solo (John 
Campbell); for (Tim B. Robinson); efelias (Eldred Felias); vikki (Vikki Vu); orlando (Orlando 

c . . t Hernando); mikew (Mike Wageman); dtacmo (Dominador Tacmo); euterpe 

Subject: Layout Review: 15 Aug 95 

Here are notes from the informal meeting to discuss 

PISil / Contact Ped fix up + additional discussion with Al and Fung 

* Geert is preparing a similar list as last time of cells that need 
Plsxl/contped repair. This time we'll work on the large cells first. 

* Goa } * s fc ? fix these cells U P h Y Friday 18 Aug so that we may start the 
verification process for a target fracture last week of August and 
ship tapes 5 September 

* S£f r ly K° n ^TV 111 bS l0Ck6d from editin 9"- plsi l ^ "p (including 
SDEC) may be edited. Be careful about undoing SDEC changes and about 
running LVS on changed cells. If you can check you cells in by 7p each 
day, Dave will automatically release them and Solo will run the necessary 
DRC and LVS checks. * 

* In the meeting we came up with an ordering of fix-ups. Subsequent 
discussion with Al and Fung modified this slightly. Here is the 
order for fixing up layouts: 

BASIC IDEA: Contact pedestal crossing Polyl-Silicide edges is to be 
avoided if at all possible 

Best: Leave 3udr PISil collar around contped 
Leave 2udr PISil collar around contped 
Use a 0.7u butting contact 
Use a 0.5u butting contact 

Leave ludr PISil collar around contped 
Worst: Leave Oudr PISil collar around contped (coincident edge) 

Hotel: these rules apply on a per edge basis. It is likely that there will 
be more than 1 edge which is affected. It is then necessary to make 
some trade-off between the above strategies for all the edges 
of the cont ped polygon in aggregate. 

Note2: If you cannot avoid crossing PISil then try to make the contact 

pedestal as wide as possible (0.7u) at the point of crossing and try 
to extend contped beyond the PISil edge as far as possible (0 85u) 
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From: 
Sent: 
To: 

Subject: 



manser [manser@charybdis] 
Tuesday, August 15, 1995 11:35 AM 
geert; John mudge; Lisa Robinson; tbr 
RE: Still waiting for.. 



Johnny, 



Your help would be greatly appreciated here. Also, I think we should dedicate some time 
on Friday of this week to review the test plan for Cronus and Euterpe given Mark W's 
departure and the accelerated schedule. 

Can you have 2-3 slides to review your organizations plan and schedule for the test of 
both of these parts? 

Alternately, we may want to expand the attendence this Friday. Comments Geert, Tim, Lisa? 



From: Lisa Robinson on Mon, Aug 14, 1995 11:48 AM 
Subject: Still waiting for . . 
To: mudge 
Cc: manser 



Johnny. 

I am still awaiting your input to the euterpe and cronus schedules for wafer test. 

I have had a stab at the euterpe flow and clearly some tasks apply both to euterpe and 
cronus. (I've put a copy in you mailbox). 

The test program development (jeffm task 88) will move in if the cronus tapeout is earlier 
than currrently shown. 

I don't have the cronus DUT board schedule and it doesn't show on Pattie's schedule as 
work in progress. 

We do continue to hold a schedule review each Wednesday at 10am and tactical reviews at 
10am on Monday and Friday. 



Steve 



Lisa R. 
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From: 



tbr 

Tuesday, August 15, 1995 1:23 AM 
wampler (Kurt Wampler) 
hopper 

Euterpe hand route 



Sent: 

To: 

Cc: 



Subject: 



Kurt Wampler wrote (on Mon Aug 14} : 
Hi, Tim - 

I've completed hand- routing of the latest Euterpe route. The dff is: 

/n/gamorra/s3/wampler/eurip/chip_euterpe-iter . dff 
There's also a netcap file: 

/n/gamorra/s3/wampler/eurip/chip_euterpe-iter.netcap 

Besides completing all of the disconnects, I went through the list of 
timing violations and made wiring improvements on every path that failed . 
cycle time. With any luck there will be very few or no additional wire 
mods needed. At your convenience, could you re-run topt and see how close 
this one comes to meeting the timing goal? If there are just a handful of 
wires', I may be able to fix them tonight... 

I have copied the .dff back to the snapshot (having saved the untouched version) because I 
have a Makefile rule setup there to make the report. It's running now. 



Tim 
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From: 
Sent: 
To: 

Subject: 



tbr 

Tuesday, August 15, 1995 1:09 AM 
graham (Graham Y. Mostyn) 
Could you assist? Thanks. 



Graham Y. Mostyn wrote (on Mon Aug 14) : 



Tim, I've finished a first draft of Friday's 
Zeus meeting, but I don't feel too confident on 
my report of the architecture discussion! 

Could you check over that section below, before I 
distribute, please? (I also forwarded it to Gmo 
for comment) 

Thanks - Graham. 



ARCHITECTURE GROUP 

Gmo presented his work on investigating how the compiler 
could reduce the number of stalls in booting Unix. 
(2 cycles are lost per stall in Euterpe's architecture.) 
Of 21 million instructions, there are 13 million stalls. 

I think "stall" should be "store" here. 

He concluded that the compiler could not contribute 
to the problem very much, other than reducing issue 
restrictions - not very significant, compared to 
D and I cache initiated stalls. 

Tim pointed out that the current Euterpe multithreaded 
architecture has high cache penalties, but offers 
guaranteed throughput, important when interaction 
must occur between threads. The appropriate benchmark is 
instructions per cycle. 

He asked what should our metric be for Zeus, a different 
architecture? We agreed that this will be clearer when we 
have isolated the main applications of interest. 

* Next step 

*not clear on this* 

Sorry, I was only able to.be in the meeting so briefly. I don't recall what was discussed 
here for the next step. 



Tim 
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From: 
Sent: 
To: 



geert (Geert Rosseel) 

Tuesday, August 1 5, 1 995 12:08 AM 

dane; dtacmo; efelias; geert; graham; hessam; hopper; mikew; ong; orlando; rich; tau; 
vanthof; vikki; wampler; yves 
jack; manser 
Euterpe Layouts : PASS II 



Cc: 

Subject: 



HI, 



It looks like the.SDEC fixes are almost completely in and we have some time before tape- 
out to fix the next set of DRV's. 

So, we'll have another pass at all the cells fixing up the silicide-contact pedestal 
interface error. There will be a meeting tomorrow (tuesday) at 10:00 in the multi-media 
room to discuss this error. 

The plan is the same as before .. I'll use the same list of cells as before and everyone 
can pick their favorite block starting from the top. 

Solo is running all blocks overnight .. so the results should be in by Tuesday morning. 

-solo/plsil/compass/* . err 



Geert 
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From: 
Sent: 
To: 

Cc: 

Subject: 



vanthof (vant) 

Monday, August 14, 1995 10:44 PM 
Mark Hofmann 

vanthof (Dave Van't Hot); torn (Tom Laidig); geert (Geert Rosseel) 
Re: fat metal adjustment 



Mark Hofmann writes: 

>They say a little knowledge is a dangerous thing. I'm dangerous... 
>Umm... okay so we remove the shrink of contact ped and vias. Then we 
>fix up (either by hand or automagically) contped and vias. _Then_ do we 
>maybe want to shrink any wide contact ped and via that has not been "fixed-i 
> (not sure how we determine that . . . ) 

> -hopper 



Well, I would like to see us fix all 'wide' vias on all via layers, including contped If 
we can achxeve that, the via shrinking can be removed. If via shrinking can be removed 
then not only is fracturing simpler and FASTER, but so are drc runs... 

That would remove 5 rather computationally intense steps from the tapeout and drc process 
We may even completely compensate for the additional time introduced by the sdec and plsil 
synthesis ... ^ 



Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
yanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... 
not in this context . " The Tick to Thrackazog 



Exhibit 5 
Page 1 1 



From: hopper (Mark Hofmann) 

Sent: Monday, August 14, 1995 3:17 PM 

To: vant 

Cc: torn (Tom Laidig); geert (Geert Rosseel); vanthof (Dave Van't Hof) 

Subject: Re: fat metal adjustment 

vant writes: 

I have a question. I now go through elaborate work to shrink wide contact 
pedestals and vias. Since we are going to fix up plsil and contact overlaps, 
and allow min spacings of 8 udrs (after biasing min x min contpeds) , this 
causes all sort of havoc with the big contped adjustments. 

I would like to remove all wide contped and via adjustment from the tapeout 
flow. This does reduce run times of the tapeout a bit (as well as drcs) . 



They say a little knowledge is a dangerous thing. I'm dangerous... 

Umm... okay so we remove the shrink of contact ped and vias. Then we fix up (either by 
hand or automagically) contped and vias. _Then_ do we maybe want to shrink any wide 
contact ped and via that has not been "fixed-up"? 
(not sure how we determine that . . . ) 

-hopper 
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From: graham (Graham Y. Mostyn) 

Sent: Monday, August 14, 1995 9:47 PM 

To: tbr 

Subject: Couid you assist? Thanks. 



Tim, I've finished a first draft of Friday's Zeus meeting, but I don't feel too confident 
on my report of the architecture discussion! 

Could you check over that section below, before I distribute, please? (I also forwarded it 
to Gmo for comment) 

Thanks - Graham. 



ARCHITECTURE GROUP 

Gmo presented his work on investigating how the compiler could reduce the number of stalls 
in booting Unix. 

<2 cycles are lost per stall in Euterpe's architecture.) Of 21 million instructions, there 
are 13 million stalls. 

He concluded that the compiler could not contribute to the problem very much, other than 
reducing issue restrictions - not very significant, compared to D and I cache initiated 
stalls. 

Tim pointed out that the current Euterpe multithreaded architecture has high cache 
penalties, but offers guaranteed throughput, important when interaction must occur between 
threads. The appropriate benchmark is instructions per cycle. 

'lie asked what should our metric be for Zeus, a different architecture? We agreed that 
this will be clearer when we have isolated the main applications of interest. 

* Next step 

*not clear on this* 
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Sent: 
To: 
Cc: 



Subject: 



From: 



graham {Graham Y. Mostyn) 
Monday, August 14, 1995 9:25 PM 
manser@charybdis 

geert; graham; hopper; tbr; lisar; mudge 
RE: Tape Out (parti) 



Great idea! 

The engineers in my group that have designed cells within Euterpe are: 

- Jean- Yves Michel 

- Rich McCauley 

- Dane Snow 

Regards, Graham. 



> From manser@charybdis Mon Aug 14 18:47:55 1995 

> Date: 14 Aug 1995 18:45:35 -0800 

> From: "manser" <manser@charybdis> 

> Subject: RE: Tape Out {part 1) 

> To: "geert" <geert@gaea> , "graham" <graham@gaea>, "hopper" <hopper@gaea>, 

> "lisar" <lisar@gaea>, "mudge" <mudge@gaea>, 

> "Tim B. Robinson" <tbr@charybdis> 

> Content -Length: 811 

> 

> Tim, Geert, Hopper, Johnny, Graham, Lisa, 

> I was hoping to get a list of folks from you (Hopper), Geert, and 

> others tomorrow to have a pizza party. Leave work around 4pm, grab 

> some pizza, and beer and relax, celebrate, etc. Nothing fancy - just a 

> breather and to recognize good progress. 

> I was thinking 12-18 people... who would you invite? 



> ps: Let me know ASAP so we can size up the number of people. Also, 

> let's keep it confidential until we have the list finalized. 



> From: Tim B. Robinson on Mon, Aug 14, 1995 4:23 PM 

> Subject: Tape Out (part 1) 

> To: euterpe 



> We have today shipped tapes for the first 14 layers (the baseplate) 

> for euterpe. 

> Thanks to everyone involved for a huge effort in making this happen. 



> Steve 



> Tim 
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From: 
Sent: 
To: 

Subject: 



manser [manser@charybdisj 

Monday, August 14, 1995 9:46 PM. 

geert; graham; hopper; lisar; mudge; Tim B. Robinson 

RE: Tape Out (part 1) 



Tim, Geert, Hopper, Johnny, Graham, Lisa, 

I was hoping to get a list of folks from you (Hopper), Geert, and others tomorrow to have 
a pizza party. Leave work around 4pm, grab some pizza and beer and relax, celebrate, etc. 
Nothing fancy - just a breather and to recognize good progress. 



ps: Let me know ASAP so we can size up the number of people. Also, let's keep it 
confidential until we have the list finalized. 

From: Tim B. Robinson on Mon, Aug 14, 1995 4:23 PM ' 
Subject: Tape Out (part 1) 
To: euterpe 



We have today shipped tapes for the first 14 layers (the baseplate) for euterpe. 
Thanks to everyone involved for a huge effort in making this happen. 



I was thinking 12-18 people. . .who would you invite? 



Steve 



Tim 
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From: vanthof (vant) 

Sent: Monday, August 14, 1 995 7:46 PM 

To: torn (Tom Laidig); hopper {Mark Hofmann); geert (Geert Rosseel) 

Cc: vanthof (Dave Van't Hof) 

Subject: fat metal adjustment 



I have a question. I now go through elaborate work to shrink wide contact pedestals and 
vias. Since we are going to fix up plsil and contact overlaps, and allow min spacings of 
8 udrs {after biasing min x min contpeds} , this causes all sort of havoc with the big 
contped adjustments. 

I would like to remove all wide contped and via adjustment from the tapeout flow. This 
does reduce run times of the tapeout a bit (as well as drcs) . 

Comments? 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context." The Tick to Thrackazog 
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From: tbr (Tim B. Robinson) 

Sent: Monday, August 14, 1 995 6:21 PM 

To: euterpe 

Subject: Tape Out (part 1) 



We have today shipped tapes for the first 14 layers (the baseplate) for euterpe. 

Thanks to everyone involved for a huge effort in making this happen. 

Tim 
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From: vanthof (vant) 

Sent: Monday, August 14, 1 995 3:59 PM 

To: hardheads 

Cc: vanthof (Dave Van't Hof) 

Subject: euterpe lower layers 



More lower layer edits have been occuring for cells that are used in euterpe. The edits 
consist of adding/removing actives and polys. 

This is not allowed as the lower layers are frozen for tapeout. 

Please refrain from modifying the following layers: 

buried, nwell, buried contact, emitter, collector plug, base polyl, 
base contact, n+active, p+active, depletion implant, natural implant, 
p+polyl, n+polyl, poly resistor, diffused resistor, undoped polyl 



Dave 



Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94 089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context." The Tick to Thrackazog 
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From: 



solo (John Campbell) 

Monday, August 14, 1995 1:38 PM 

Lisa Robinson 

brianl (Brian Lee); geert (Geert Rosseel); wingard (Drew Wingard); tbr (Tim B. Robinson) 
Re: atlas build , . 



Sent: 
To: 
Cc: 



Subject: 



as Lisa Robinson was saying 



.Brian Lee wrote {on Mon Aug 14) : 
John Campbell writes: 
brianl 

lisar has suggested that i try and build atlas and you are the one who 
knows what the magic dust must be made of. 



..Let's just be clear about what we are doing here. John is building the . .cronus atlas 
and chaos trees. They shoukd be built as chip and thay ..will be used for cronus tapeout. 

I think that having atlas/chaos -> /u/chip/chaos is fine for now. Though, 
realize that you are then affected by ongoing releases in /u/chip/chaos. 
Are you going to be building chaos also? If so, perhaps you can point to 
it instead. 

..I absolutely disagree. Chaos should be built too. 



so i will build a script that checks out and builds chaos followed by a build of atlas, i 
will put them on s52/snapshot 



Brian L. 



Lisa R. 



regards , 

solo a.k.a. John Campbell 



X516 
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From: 



lisar (Lisa Robinson) 

Monday, August 14, 1995 1:35 PM 

briani (Brian Lee); solo 

geert; wingard; tbr 

Re: atlas build 



Sent: 
To: 
Cc: 



Subject: 



Brian Lee wrote {on Mon Aug 14) : 
John Campbell writes: 
briani 

lisar has suggested that i try and build atlas and you are the one who . 
knows what the magic dust must be made of. 

Let's just be clear about what we are doing here. John is building the cronus atlas and 
chaos trees. They shoukd be built as chip and thay will be used for cronus tapeout. 

can you advise me as to how to make sure we have the right amount of 
chaos and altlas mixed together to make this happbn properly. 

what i think we did back in april was: 
getbom of atlas. 

"In -s . ./atlas" ; 

"In -s . . /tools" ; 

"In -s ../technology"; 

"In -s /u/chip/chaos" ,- 

i am not sure whether we has a link to ../chaos, i don't think so. 

I think that having atlas/chaos -> /u/chip/chaos is fine for now. Though, 
realize that you are then affected by ongoing releases in /u/chip/chaos. 
Are you going to be building chaos also? If so, perhaps you can point to 
it instead. 

I absolutely disagree. Chaos should be built too. 

and " . . " contaned links to /u/chip/chaos /u/chip/altlas, tools, and technology 
then gmake 

Scratch the /u/chip/altlas link; otherwise, everything looks fine to me. 
Good luck, 



Brian L. 



Lisa R. 
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From: 



torn (Tom Laidig [tau]) 

Monday, August 1 4, 1 995 1 2:34 PM 

Kurt Wampler 

hopper (Mark Hofmann); tau; tbr (Tim B. Robinson); vanthof (Dave Van't Hot) 
RE: fracture crash 



Sent: 

To: 

Cc: 



Subject: 



Kurt Wampler writes: 
Tom Laidig writes: 



>Could we start a verification that a tapeout of the layouts in 
>/n/cyclops/sl/dracjobs/immlayouts2 would produce the same 010-140 
>patterns that we have now? This would be just a form of xor-check, I 
>think. No fracture output or DRCs needed. 

>I _think_ our current tapes are OK, but as I've mentioned in other 
>messages, I was a bit late getting the script in place to verify that 
>lower layers hadn't been accidentally changed, and I'm not certain 
>what might have been in the snapshot when the fracture flow was 
flattening its input. 

I can start this up. What vlsi.boo file should be used for this 
comparison? I don't find one in that directory... 

No, there is no .boo file there; it is a single directory that contains all layouts. So 
you can either create a .boo file somewhere or run the fracture with the --p 
/n/cyclops/sl/dracjobs/immlayouts2 • option, whichever is easier. 

T think that, in the future, we'll continue to do staged tapeouts, and we'll be doing the 
iarly fractures at least from a single directory that contains copies of all layouts 
(probably the same one that the final DRC created) . So you might want to think about 
setting things up so that's easy to do. 
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From: 



wampler (Kurt Wampler) 

Monday, August 14, 1995 12:00 PM 

torn 

hopper; tau; tbr; vanthof 
RE: fracture crash 



Sent: 

To: 

Cc: 



Subject: 



Tom Laidig writes: 



>Could we start a verification that a tapeout of the layouts in 
>/n/cyclops/sl/dracjobs/immlayouts2 would produce the same 010-140 
>patterns that we have now? This would be just a form of xor-check, I 
>think. No fracture . output or DRCs needed. 

>I _think_ our current tapes are OK, but as I've mentioned in other 
>messages, I was a bit late getting the script in place to verify that 
>lower layers hadn't been accidentally changed, and I'm not certain what 
>might have been in the snapshot when the fracture flow was flattening 
>its input. 

I can start this up. What vlsi.boo file should be used for this 
comparison? I don't find one in that directory... 



Kurt 
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Prom: hopper (Mark Hofmann) 

Sent: Monday, August 1 4, 1 995 4:57 AM 

To: Tom Laidig [tau] 

£ C L . 4 wampler (Kurt Wampler); tau; vanthof (Dave Van't Hot); tbr (Tim B. Robinson) 

Subject: RE: fracture crash 

Tom Laidig [tau] writes: 

Could we start a verification that a tapeout of the layouts in 
/n/cyclops/sl/dracjobs/immlayouts2 would produce the same 010-140 
patterns that we have now? This would be just a form of xor-check, I 
think. No fracture output or DRCs needed. 

I _think_ our current tapes are OK, but as I-ve mentioned in other 
messages, I was a bit late getting the script in place to verify that 
lower layers hadn't been accidentally changed, and I'm not certain what 
might have been m the snapshot when the fracture flow was flattening 
its input. 3 
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From: 



torn (Tom Laidig [tau]) 

Monday, August 14, 1995 11:55 AM 

wampler (Kurt Wampler) 

tau; vanthof (Dave Van't Hot); hopper (Mark Hofmann); tbr (Tim B. Robinson) 
RE: fracture crash 



Sent: 

To: 

Cc: 



Subject: 



Tom Laidig [tau] writes: 

Also, we need to prepare for a final fracture run where we verify that 
a lower- layer fracture now would produce the same tapes we sent 
yesterday (or some such combination of verb tenses). I'd like to fire 
up such a comparison now for layers 010-110. 

Could we start a verification that a tapeout of the layouts in 

/n/cyclops/sl/dracjobs/immlayouts2 would produce the same 010-140 patterns that we have 
now? This would be just a form of xor-check, I think. No fracture output or DRCs needed. 

I _think_ our current tapes are OK, but as I've mentioned in other messages, I was a bit 
late getting the script in place to verify that lower layers hadn't been accidentally 
changed, and I'm not certain what might have been in the snapshot when the fracture flow 
was flattening its input. 
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from: manser [manser@charybdis] 

Sent: Monday, August 14, 1995 11:27 AM 

To: doi@charybdis; gmo@charybdis; guarino@charybdis; iimura@charybdis; ieffm@charybdis- 

Lisa Robinson ' 
. euterpe@charybdis; manser@charybdis; software@charybdis; sysadm@charybdis 

Subject: RE: OSF1 kernel boot test: PASSED y 



Great news! Keep up the great work! 
Steve 

From: Lisa Robinson on Mon, Aug 14, 1995 7:38 AM 
Subject: OSF1 kernel boot test: PASSED 
To: doi; gmo; guarino; iimura; jeffm 
Cc: euterpe; manser,- software; sysadm 



hdo 
hdl 
hd2 
hd3 



The OSF1 kernel boot test has just PASSED after running continuously for 8 days. 

Yeah! 

Lisa R. 

Here are the messages printed during its execution. 

Terp boot: memory from 0x140000 to 0x800000 

Kernel dynamic virtual space from Oxfff 100 0 00 0000 000 

to 0xfffl000004000000. 

OSF1 Release 1.1 (oscl.l); Fri Jul 14 15:41:16 PDT 1995; HWS1M (pippin) 
physical memory =8.00 megabytes, 
available memory = 4 . 6 megabytes . 

using 102 buffers containing 0.79 megabytes (10%) of memory 
' disk unit is not defined, 

disk unit is not defined, 
disk unit is not defined, 
disk unit is not defined, 
mtprobe: 4 simulated tapes configured, terp.mt? 
OSF1 kernel boot test: PASSED 

We are now about 1/5 the way to booting to single user prompt. Note that the configured 
simuator used was gave lower performance than the simulator that will be used for the full 
OSF run. The full run should take about 10 days. 

--Here is a cut from previous posted mail 

We had a short discussion about the progress of the shortened OSF test that is being run 
on the HW simulator. 3 
-- cut-- 

Once this test has run, the following steps have been accomplished. 

o kernel data structures will have been initialized 
o the "probe ' steps have been faked' out . 
o all kernel memory is setup 

- dynamic pages for text 

- buffer caches 

The above steps are estimated to take about 30 milliseconds wall clock time, 
hat remains to get us to a single user prompt? 
o mach_init 
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o init 

o exec of a shell 

The total wall clock time estimate to do the entire boot and arrive at a single user 
prompt is about 150 milliseconds (not accounting for disk I/O) . 
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From: lisar (Lisa Robinson) 

Sent: Monday, August 14, 1 995 9:38 AM 

To: doi; gmo; guarino; iimura; jeffm 

Cc: euterpe; manser; software; sysadm 

Subject: OSF1 kernel boot test: PASSED 



The OSF1 kernel boot test has just PASSED after running continuously for 8 days. 

Yeah! 

Lisa R. 

Here are the messages printed during its execution. 

Terp boot: memory from 0x140000 to 0x800000 

Kernel dynamic virtual space from Oxfff 1000000000000 

to Oxfff 1000004000000. 

OSF1 Release 1.1 (oscl.l); Fri Jul 14 15:41:16 PDT 1995; HWSIM (pippin) 
physical memory = 8.00 megabytes, 
available memory = 4.6 megabytes. 

using 102 buffers containing 0.79 megabytes (10%) of memory 
disk unit is not defined, 
disk unit is not defined, 
disk unit is not defined, 
disk unit is not defined, 
mtprobe: 4 simulated tapes configured, terp.mt? 
OSF1 kernel boot test: PASSED 

ie are now about 1/5 the way to booting to single user prompt. Note that the configured 
sxmuator used was .gave lower performance than the simulator that will be used for the full 
OSF run. The full run should take about 10 days. 



hdO 
hdl 
hd2 
hd3 



-Here is a cut from previous posted mail 



We had a short discussion about . the progress of the shortened OSF test that is being run 
on the HW simulator. 
-- cut-- 

Once this test has run, the following steps have been accomplished. 

o kernel data structures will have been initialized 
o the "probe' steps have been faked out. 
o all kernel memory is setup 

- dynamic pages for text 

- buffer caches 

The above steps are estimated to take about 30 milliseconds wall clock time. 

What remains to get us to a single user prompt? 

o mach_init 
o init 

o exec of a shell 

The total wall clock time estimate to do the entire boot and arrive at a single user 
prompt is about 150 milliseconds (not accounting for disk I/O) . 
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From: lisar (Lisa Robinson) 

Sent: Monday, August 14, 1995 9:38 AM 

To: doi; gmo; guarino; iimura; jeffm 

Cc: euterpe; manser; software; sysadm 

Subject: OSF1 kerne! boot test PASSED 



The OSP1 kernel boot test has just PASSED after running continuously for 8 days. 

Yeah! 

Lisa R. 

Here are the messages printed during its execution. 

Terp boot: memory from 0x140000 to 0x800000 

Kernel dynamic virtual space from Oxfff 1000000000000 

to Oxfff 1000004000000. 

OSF1 Release 1.1 (oscl.l); Fri Jul 14 15:41:16 PDT 1995; HWSIM (pippin) 
physical memory =8.00 megabytes, 
available memory = 4.6 megabytes. 

using 102 buffers containing 0.79 megabytes (10%) of memory 

hdO: disk unit is not defined. 

hdl: disk unit is not defined. 

hd2: disk -unit is not defined. 

hd3: disk unit is not defined. 

mtprobe: 4 simulated tapes configured, terp.mt? 

OSF1 kernel boot test: PASSED 

We are now about 1/5 the way to booting to single user prompt. Note that the configured i 
simuator used was gave lower performance than the simulator that will be used for the full 
OSF run. The full run should take about 10 days. 

Here is a cut from previous posted mail 

We had a short discussion about the progress of the shortened OSF test that is being run 
on the HW simulator. 
-- cut-- 

Once this test has run, the following steps have been accomplished. 

o kernel data structures will have been initialized 
o the "probe' steps have been faked out. 
o all kernel memory is setup 

- dynamic pages for text 

- buffer caches 

The above steps are estimated to take about 30 milliseconds wall clock time. 

What remains to get us to a single user prompt? 

o mach_init 
o init 

o exec of a shell 

The total wall clock time estimate to do the entire boot and arrive at a single user 
prompt is about 150 milliseconds (not accounting for disk I/O) . 
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From: 



Mark Hofmann [hopper@gaea.microunity.com] 

Monday, August 14, 1 995 1:31 AM 

vant 

geert@microunity.com; Lisa Robinson; Tim B. Robinson; Drew Wingard; Dave Van't Hof 
Re: A Cronus baseplate ready for DRC .. 



Sent: 
To: 
Cc: 



Subject: 



vant writes: 

The problem with drc jobs dieing is not with the flow, but with dracula. 
There appears to be a bug in dracula that causes the SIZE module to bomb 
out. I ran a test on hestia with the latest version of dracula and it 
worked on a block that used to fail. However, when I had tacmo try it 
out, his whole environment was messed up and no dracula binaries were found. 

I can have some one else try a test tomorrow to help track down the 
environment problem. If it does work, then I can have a couple of machines 
upgraded with this new version. 

I'm leary about installing this new version of dracula just as we are 
trying to tapeout euterpe. There could be some subtle differences in the 
tool which will cause all kinds of problems when we least need them. 



If you need a guinea pig to start off a run, I can try out my environment. 



Dave, 



-thanks, 
hopper 
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From: 
Sent: 
To: 
Cc: 



hopper (Mark Hofmann) 
Monday, August 14, 1995 1:31 AM 
vant 

geert@microunity.com; lisar (Lisa Robinson); tbr (Tim B. Robinson); wingard (Drew WingardV 

vanthof (Dave Van't Hot) 

Re; A Cronus baseplate ready for DRC .. 



Subject: 



vant writes : 

The problem with drc jobs dieing is not with the flow, but with dracula. 
There appears to be a bug in dracula that causes the SIZE module to bomb 
out. I ran a test on hestia with the latest version of dracula and it 
worked on a block that used to fail . However, when I had tacmo try it 
out, his whole environment was messed up and no dracula binaries were found. 

I can have some one else try a test tomorrow to help track down the 
environment problem. If it does work, then I can have a couple of machines 
upgraded with this new version. 

I'm leary about installing this new version of dracula just as we are 
trying to tapeout euterpe. There could be some subtle differences in the 
tool which will cause all kinds of problems when we least need them. 



If you need a guinea pig to start off a run, I can try out my environment. 



Dave, 



-thanks, 
hopper 
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From: 



vanthof (vant) 

Monday, August 14, 1995 12:12 AM 
Geert Rosseel 

hopper (Mark Hofmann); lisar (Lisa Robinson); tbr (Tim B. Robinson); wingard (Drew 
Wingard); vanthof (Dave Vant Hof) 
Re: A Cronus baseplate ready for DRC .. 



Sent: 

To: 

Cc: 



Subject: 



Geert Rosseel writes: 



> Hi, 

> I think I have a baseplate ready for toplevel DRC. I still need to do 
>sorae more work on clock connections, but most of it is there. 

> 

> I know the CSM flow still dies on a couple of large blocks ( I also 
>know that Dave is very busy . . ) . 

> I'd like to try a toplevel DRC as soon as possible to see how long it 
>takes and to find algorithmicly generated DRV's. 

> Can someone (maybe someone else than Dave) have a look at the flow ? 
> 

> with some luck, we should be able to run an LVS shorts test by the end 
>of the week. 



jThe problem with drc jobs dieing is not with the flow, but with dracula. 
There appears to be a bug in dracula that causes the SIZE module to bomb out. I ran a 
test on hestia with the latest version of dracula and it worked on a block that used to 
fail. However, when I had tacmo try it out, his whole environment was messed up and no 
dracula binaries were found. 

I can have some one else try a test tomorrow to help track down the environment problem. 
If it does work, then I can have a couple of machines upgraded with this new version. 

I'm leary about installing this new version of dracula just as we are trying to tapeout 
euterpe. There could be some subtle differences in the tool which will cause all kinds of 
problems when we least need them. 



Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context." The Tick to Thrackazog 



Geert 



Dave 
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From: vanthof (vant) 

Sent: Monday, August 14, 1995 12:12 AM 

To: Geert Rosseel 

Cc: hopper (Mark Hofmann); lisar (Lisa Robinson); tbr (Tim B. Robinson); wingard (Drew 

Wingard); vanthof (Dave Van't Hot) 
Subject: Re: A Cronus baseplate ready for DRC .. 



Geert Rosseel writes: 
> 

> Hi, 
> 

> I think I have a baseplate ready for toplevel DRC. I still need to do 
>some more work on clock connections, but most of it is there. 

> I know the CSM flow still dies on a couple of large blocks ( I also 
>know that Dave is very busy . . ) . 

> I'd like to try a toplevel DRC as soon as possible to see how long it 
>takes and to find algorithmicly generated DRV's. 

> 

> Can someone (maybe someone else than Dave) have a look at the flow ? 

> with some luck, we should be able to run an LVS shorts test by the end 
>of the week. • 

>' Geert 



The problem with drc jobs dieing is not with the flow, but with dracula. i 
There appears to be a bug in dracula that causes the SIZE module to bomb out. I ran a 
test on hestia with the latest version of dracula and it worked on a block that used to 
fail. However, when I had tacmo try it out, his whole environment was messed up and no 
dracula binaries were found. 

I can have some one else try a test tomorrow to help track down the environment problem. 
If it does work, then I can have a couple of machines upgraded with this new version. 

I'm leary about installing this new version of dracula just as we are trying to tapeout 
euterpe. There could be some subtle differences in the tool which will cause all kinds of 
problems when we least need them. 



Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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•rom: vanthof (vant) 

Sent: Sunday, August 13, 199511:04 PM 

to: KurtWampler 



Object: HOf>: h ° PPer (Mafk HOfmann); tbP (Tim B " R ° binson ) ; tom < Tom Laidig) 



Kurt Wampler writes.- 



>Well. . i logged in with the intent of responding to the pages from 

Sof^n T ° m ' bUt ^ apPSarS that in th * -«n time (afLfreSng the 
>4 0+ email messages that had stacked up since this morning) that Tom has 
SST e ? h fraCtUre .° f la Y*™ 120-140. As long as no moSfgetboms are 
Shere a~ n "^i" 8 ' those la ^s should complete successfully. 
>There are no post- fracture DRC errors at this time to be scrutinized. 

>ln a way, I think we have just proved to ourselves that we weren't 

-^Vw* 7 y ? fc to . ta P e this chi P <™t. The number of edits & checking 
>of lLT^ PlaCe " rather alarmin *- «hat I *would* like to get out 

> 1) Interface between frame & die 

> 2) Layers with complex synthesis formulae <Vt, P/N, emitter implants) 
>frac?uref so ^^ Confident about dipping any of the layers we-ve 

"ILll Stay lG ? ged in th±S aftern °°* if there are any dangling loose ends 

that you need me to work on. Have we got the fatwire pad target 
problem sufficiently fixed so that Tim can launch a neS place f route? 
>- Kurt 

Well, I do feel pretty confident about the fracture job and in fact would like to sh-ir, 
tapes on monday. Tom has put together a script which is compLlng two dLeSorSs of P 

ST-= — ~ - ~~ sir J£i£r 
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From: tbr 

Sent: Sunday, August 13, 1 995 5:1 1 PM 

To: torn (Tom Laidig [tau]) 

£ c: hopper (Mark Hofmann); tau; vantbof (Dave Van't Hof); Kurt Wampler 

Subject: RE: fracture crash 



Tom Laidig [tau] wrote (on Sun Aug 13): 

Kurt Wampler writes: 

Well ... I logged in with the intent of responding to the pages from Hopper 
and Tom, but it appears that in the mean time (after reading the 40+ email 
messages that had stacked up since this morning) that Tom has restarted 
fracture of layers 120-140. As long as no more getboms are done in the 
mean txme, those layers should complete successfully. There are no 
post- fracture DRC errors at this time to be scrutinized. 

Yeah, things happen fast sometimes... thanks for checking the 
post-fracture DRC results. BTW, I moved the previous euterpe_lower.log 
to euterpe_lower.log. 2, in case people want to look at it. 



In a way, I thxnk we have just proved to ourselves that we weren't really 
ready yet to tape this chip out. The number of edits & checkins still 
taking place is rather alarming. 

Well, we're obviously not ready yet to tape out the upper layers, and I 
think we've proven that we weren't methodologically ready to tape out 
the lower layers while the upper layers are still in flux. I think 
we're more ready to do that kind of thing now. It seems to me that 
there were two main things wrong with our methodology: 

we didn't have an automated check in place to be alert to lower 
layer changes 

This has been fixed: a check is made every 4 hours, with error 
mail sent to me and dave (anybody else want to be on the "to' 
list?) 

we should have started the fracture on a separate copy of the 
layouts 

I think this is something we should address before we embark on 
another gradual tapeout. Since it seems likely that most such 
tapeouts would happen simultaneously with the launching of the 
final DRC run (as happened this time), perhaps it makes sense 
for the DRC and fracture to share the frozen layout directory. 

I think so, and in fact I had been assuming that was the case this time. Obviously in the 
ideal case the snapshot would be just that and we'd not have this problem. 

Also, we need to prepare for a final fracture run where we verify that 
a lower- layer fracture now would produce the same tapes we sent 
yesterday (or some such combination of verb tenses). I'd like to fire 
up such a comparison now for layers 010-110. 

Of course, personally, the idea of taping out lower layers while the 
uppers are still being furiously edited makes me want to take the 
metaphorical equivalent of a long hot shower. Sadly, the economics of 
txme suggest that we'd better get used to doing business this way. I 
certainly can't justify delaying each tapeout by 2 or 3 weeks (equals 
$700k-$lM of fab burn or something?) for a little methodological purity 
and peace of mind. 
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1) Interface between frame & die 

2) Layers with complex synthesis formulae (vt, P/ N , emitter implants) 
so d rar?. feel ^ C ° nfldent about dipping any of the layers we've fractured 

ISiJ«™f^ PeCt f? ip ' em aa y* a y» and run some more post -hoc 

ISs^^st 3 : H ° PefUlly ' We '" be l«*y — ^ve to retract only a few 

I'll stay logged in this afternoon if there are any danglinq loose ends 

I think we hope this is the case, but I sure couldn't say... 

OK so far" m ° re h ° UrS bef ° re " gStS paSt the place *»» i- -ashed last time, but 
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From: 
Sent: 
To: 
Cc: 



torn {Tom Laidig [tauj) 

Sunday, August 13, 1995 4:43 PM 

Kurt Wampler 

tau; hopper (Mark Hofmann); tbr (Tim B. Robinson); vanthof (Dave Van't Hof) 
RE: fracture crash 



Subject: 



Kurt Wampler writes: 

Well ... I logged in with the intent of responding to the pages from 
Hopper and Tom, but it appears that in the mean time (after reading the 
40+ email messages that had stacked up since this morning) that Tom has 
restarted fracture of layers 120-140. As long as no more getboms are 
done in the mean time, those layers should complete successfully. 
There are no post-fracture DRC errors at this time to be scrutinized. 

Yeah, things happen fast sometimes... thanks for checking the post-fracture DRC results. 
BTW, I moved the previous euterpe_lower.log to euterpe_lower . log . 2 , in case people want to 

1 nnlr af ih 



In a way, I think we have just proved to ourselves that we weren't 
really ready yet to tape this chip out. The number of edits & checkins 
still taking place is rather alarming. 

Well, we're obviously not ready yet to tape out the upper layers, and I think we've proven 
that we weren't methodologically ready to tape out the lower layers while the upper layers 
are still in flux. I think we're more ready to do that kind of thing now. It seems to me 
that there were two main things wrong with our methodology: 

we didn't have an automated check in place to be alert to lower 
layer changes 

This has been fixed: a check is made every 4 hours, with error 
mail sent to me and dave (anybody else want to be on the "to" 
list?) 

we should have started the fracture on a separate copy of the 



I think this is something we should address before we embark on 
another gradual tapeout. Since it seems likely that most such 
tapeouts would happen simultaneously with the launching of the 
final DRC run (as happened this time) , perhaps it makes sense 
for the DRC and fracture to share the frozen layout directory. 

Also, we need to prepare for a final fracture run where we verify that a lower-layer 
fracture now would produce the same tapes we sent yesterday (or some such combination of 
verb tenses) . I'd like to fire up such a comparison now for layers 010-110. 

Of course, personally, the idea of taping out lower layers while the uppers are still 
being furiously edited makes me want to take the metaphorical equivalent of a long hot 
shower. Sadly, the economics of time suggest that we'd better get used to doing business 
this way. I certainly can't justify delaying each tapeout by 2 or 3 weeks (equals 
$700k-$lM of fab burn or something?) for a little methodological purity and peace of mind. 

What I *would* like to get out of 
this fracture exercise is a good look at the lower layers on Monday, 
paying particular attention to: 

1) Interface between frame & die 

2) Layers with complex synthesis formulae <Vt, P/N, emitter implants) 

I don't feel very confident about shipping any of the layers we've 
fractured so far. 



layouts 
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Well, I suspect we'll ship 'em anyway, and run some more post-hoc verifications 
Hopefully, we'll be lucky and have to retract only a few tapes at most. 

I'll stay logged in this afternoon if there are any dangling loose ends 
that you need me to work on. Have we got the fatwire pad target 
problem sufficiently fixed so that Tim can launch a new place & route? 

I think we hope this is the case, but I sure couldn't say. 
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From: 



hopper (Mark Hofmann) 
Sunday, August 13, 1995 9:24 AM 
KurtWampler 

tbr (Tim B. Robinson); torn (Tom Laidig); vanthof (Dave Van't Hof) 
RE; fracture crash 



Sent: 

To: 

Cc: 



Subject: 



Kurt Warapler writes: 

Well ... I logged in with the intent of responding to the pages from Hopper 
and Tom, but it appears that in the mean time (after reading the 40+ email 
messages that had stacked up since this morning) that Tom has restarted 
fracture of layers 120-140. As long as no more getboms are done in the 
mean time, those layers should complete successfully. There are no 
post-fracture DRC errors at this time to be scrutinized. 

In a way, I think, we have just proved to ourselves that we weren't really 
ready yet to tape this chip out. The number of edits & checkins still 
taking place is rather alarming. What I *would* like to get out of this 
fracture exercise is a good look at the lower layers on Monday, paying 
particular attention to: 

1) Interface between frame & die 

2) Layers with complex synthesis formulae (Vt, P/N, emitter implants) 
I don't feel very confident about shipping any of the layers we've fractured 



Okay. I think we would like to start another, parallel, fracture run pointing to the 
"immlayout2» (sp?) area. Do you think that reasonable? 

I'll stay logged in this afternoon if there are any dangling loose ends 
that you need me to work on. Have we got the fatwire pad target problem 
sufficiently fixed so that Tim can launch a new place & route? 

I don't believe so, unless Geert has been able to address the problem. 



so far . . . 



- Kurt 



-hopper 



Exhibits 
Page 38 



From: wampler (Kurt Wampler) 

Sent: Sunday, August 1 3, 1 995 4:21 PM 

To: hopper; tbr; torn; vanthof 

Subject: RE: fracture crash 



Well ... I logged m with the intent of responding to the pages from Hopper and Tom, but it 
appears that an the mean time (after reading the 40+ email messages that had stacked up 
since this morning) that Tom has restarted fracture of layers 120-140. As long as no more 
getboms are done in the mean time, those layers should complete successfully. There are 
no post- fracture DRC errors at this time to be scrutinized. 

In a way, I think we have just proved to ourselves that we weren't really ready yet to 
tape this chip out. The number of edits & checkins still taking place is rather alarming. 
What I *would* like to get out of this fracture exercise is a good look at the lower 
layers on Monday, paying particular attention to: 

1) Interface between frame & die 

2) Layers with complex synthesis formulae (Vt, P/N, emitter implants) 

I don't feel very confident about shipping any of the layers we've fractured so far... 

I'll stay logged in this afternoon if there are any dangling loose ends that you need me 
to work on. Have we got the fatwire pad target problem sufficiently fixed so that Tim can 
launch a new place & route? 
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From: 



hopper (Mark Hofmann) 
Sunday, August 13, 1995 7:44 AM 
Tom Laidig [tau] 

wampler (Kurt Wampler); vanthof (Dave Van't Hof); tau; tbr (Tim B. Robinson); tisar (Lisa 
Robinson); geert (Geert Rosseel) 
Re: fracture died 



Sent: 
•To: 
Cc: 



Subject: 



Tom Laidig [tau] writes: 

(this is mostly a summary of previous mail messages) 

The fracture flow died this morning because it couldn't find a cell in 
the hierarchy. This happened because we're fracturing from the 
snapshot, which has been updated periodically while the fracture was in 
progress, and at least one such update brought it to an inconsistent 
state. 

We seem to have layers 010-110 finished, so we want to restart the 
fracture flow on layers 120-140. I can see how to do this, except that 
I'd also like to change the .boo file (which seems to be auto -generated 
in some way) so it takes layouts strictly from the directory 
/n/cyclops/sl/dracjobs/immlayouts2 (which is a frozen directory of 
layouts as they existed when the current lower- layer DRC run started) . 
Can you set this up? 

Also, I'm a bit worried about other layers being corrupt. There have 
been a distressing number of cases where people did silicon- layer edits 
while fixing SDEC problems, and although Dave has caught these and 
backed them out, I worry that they may have been in the snapshot for a 
time before we got the mechanisms in place to detect them in a timely 
fashion. Therefore, I'd like to start up a run to. generate 010-110 from 
the /n/cyclops/sl/dracjobs/immlayouts2 directory, and verify that the 
results are the same as what we have fractured already. I think this 
work can proceed in parallel with sending out the tapes. 



This sounds like a good way to proceed. Maybe in parallel with Kurt fixing up the .boo 
file you could do a restart on 120-140 pointing to the snapshot, just to finish off (and 
blunder- sweep) the fracture run? 



> Tom, 



-thanks, 
hopper 
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From: 



torn {Tom Laidig [tau]) 

Sunday, August 13, 1995 2:38 PM 

wampler (Kurt Wampler) 

hopper (Mark Hofmann); vanthof (Dave Van't Hof); tau; tbr (Tim B. Robinson); lisar (Lisa 
Robinson); geert (Geert Rosseel) 
fracture died 



Sent: 

To: 

Cc: 



Subject: 



(this is mostly a summary of previous mail messages) 

The fracture flow died this morning because it couldn't find a cell in the hierarchy. 
This happened because we're fracturing from the snapshot, which has been updated 
periodically while the fracture was in progress, and at least one such update brought it 
to an inconsistent state. 

We seem to have layers 010-110 finished, so we want to restart the fracture flow on layers 
120-140. I can see how to do this, except that I'd also like to change the .boo file 
(which seems to be auto -generated in some way) so it takes layouts strictly from the 



/n/cyclops/sl/dracjobs/immlayouts2 (which is a frozen directory of layouts as they existed 
when the current lower- layer DRC run started) . 
Can you set this up? 

Also, I'm a bit worried about other layers being corrupt. There have been a distressing 
number of cases where people did silicon- layer edits while fixing SDEC problems, and 
although Dave has caught these and backed them out, I worry that they may have been in the 
snapshot for a time before we got the mechanisms in place to detect them in a timely 
fashion. Therefore, I'd like to start up a run to generate 010-110 from the 
/n/cyclops/sl/dracjobs/immlayouts2 directory, and verify that the results are the same as 
what we have fractured already. I think this work can proceed in parallel with. sending 

>Yllh t-.h« l-arwo . 3 



directory 



but the tapes. 
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From: 



hopper (Mark Hofmann) 

Saturday, August 12, 1995 10:33 AM 

vant 

hopper@microunity.com; torn (Tom Laidig); tbr (Tim B. Robinson); geert (Geert Rosseel); 

vanthof (Dave Van't Hof) 

Re: output of euterpe/.checkoutrc (fwd) 



( 



Sent: 
To: 
Cc: 



Subject: 



vant writes: 

Mark Hofmann writes: 

>I _think_ so, but I'm not sure. It sounds like these are the upper layers 
>of the pads so they shouldn't affect the lower tape out layers. And I assume 
>they've been LVS'd and DRC'd. . . 

At this point, I think it is a bad assumption to think they are 
drc/lvs clean. 

Lot's of careless mistakes are being made with no verification done before 
checkins occur, because of this, I believe the next fullchip lvs will 
be a disaster ... 



Arg. I fear you may be right. I think not a lot of the edit cells have undergone the full 
DRC. I think that's how many of them ended up on Solo's list still dirty. 



Dave 



-hopper 
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From: vanthof (vant) 

Sent: Saturday, August 12, 1995 4:05 PM 

To: Mark Hofmann 

Cc: torn (Tom Laidig); tbr (Tim B. Robinson); geert (Geert Rosseel); vanthof (Dave Van't Hof) 

Subject: Re: output of euterpe/.checkoutrc (fwd) 



Mark Hofmann writes: 

>I _think_ so, but I'm not sure. It sounds like these are the upper 
>layers of the pads so they shouldn't affect the lower tape out layers. 
>And I assume they've been LVS'd and DRC'd... 

>-hopper 



At this point, I think it is a bad assumption to think they are drc/lvs clean. 

Lot's of careless mistakes are being made with no verification done before checkins occur. 

because of this, I believe the next fullchip lvs will be a disaster... 

Dave 



Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1408734-8100 

"I don't know the meaning of the word surrender 1 I mean, I know it, I'm not dumb iust 
not in this context." The Tick to Thrackazog 
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From: 



lisar (Lisa Robinson) 

Saturday, August 12, 1995 2:30 PM 

Charlie Root 

brian; deepak; jeffm; tbr; veena 

Derek has a question about verilog wires.... 



Sent: 

To: 

Cc: 



Subject: 



Charlie Root wrote (on Sat Aug 12): 



I am having trouble getting my C model to actually wiggle wires. To 
test an idea that Brian Smith gave me, I created two things 
(variables?) . 



And replaced that use of PciDEVSEL with wiredevsel and regdevsel . 
When I use undertow, I can verify that the regdevsel value can be 
changed by my model but the wiredevsel one does not. 

I have a feeling the problem is related to a verilog type problem in 
that I am not expressing my ability to drive the signals (perhaps 
wires default to be inputs instead of inouts?) . 

I was wonding if any of you were logged in today and might be able to 
suggest something. 

The verilog code I am using is in 



I don't think that I can be much here but are you sure that you are the only one driving 
the wires? If you are driving the wires with someething that doesn't "force" them they 
could be getting clobbered by something else, even an X or a Z (if they are floating for 
example) . You cannot guarantee the order of evaluation in the same simtick. 



wire 
reg 



wiredevsel; 
regdevsel ,- 



/u/doi/ chip/euterpe/verilog/bsrc/hc . test/pcitest . v 



Thanks , 
doi 



Lisa R. 
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From: 



tbr 

Saturday, August 12, 1995 2:22 PM 
hopper (Mark Hofmann) 

geert (Geert Rosseel); tau; Tom Laidig [tau]; vanthof (Dave Van't HoO 
Re: output of euterpe/.checkoutrc (fwd) 



Sent: 

To: 

Cc: 



Subject: 



Mark Hofmann wrote (on Sat Aug 12) : 

Tom Laidig [tau] writes: 

I think this is the result of Tim doing a top-level release of euterpe. 
It died trying to abstract the baseplate, because it couldn't find the 
layout files: 

padcrack_uplay . ly 
padseal_uplay.ly 
padm . ly 

which are in proteus/compass/ layouts, but haven't been released. I'm 
guessing vant's blanket release last night missed them because his cell 
list is newly out of date -- these cells were first created yesterday. 

Should I release them now? 



I _think_ so, but I'm not sure. It sounds like these are the upper layers 
of the pads so they shouldn't affect the lower tape out layers. And I assume 
they've been LVS'd and DRC'd. . . 

There is another problem wher 3 handle with. care nets not routing. 

Geert is looking at it but has not found anything wrong. Could this be related? 



[snip] 



Tim 



Exhibit 5: 
Page 45 



From: hopper (Mark Hofmann) 

Sent: Saturday, August 12, 1 995 7:14 AM 

To: Tom Laidig [tau] 

Cc: tbr (Tim B. Robinson); vanthof (Dave Van't Hof); tau; geert (Geert Rosseel) 

Subject: Re: output of euterpeV.checkoutrc (fwd) 

Tom Laidig [tau] writes: 

I think this is the result of Tim doing a top-level release of euterpe. 
It died trying to abstract the baseplate, because it couldn't find the 
layout files : 

padcrack_uplay . ly 
padseal_uplay . ly 
padm . ly 

which are in proteus/compass/layouts, but haven't been released. I'm 
' guessing vant's blanket release last night missed them because his cell 
list is. newly out of date -- these cells were first created yesterday. 

Should I release them now? 



[snip] 

I _think_ so, but I'm not sure. It sounds like these are the upper layers of the pads so 
they shouldn't affect the lower tape out layers. And I assume they've been LVS'd and 
DRC'd. . . 

-hopper 
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From: 



torn (Tom Laidig [tau]) 

Saturday, August 12, 1995 1:43 PM 

tbr (Tim B. Robinson); vanthof (Dave Van't HoO 

tau; hopper (Mark Hofmann); geert (Geert Rosseel) 

output of euterpe/.checkoutrc (fwd) 



Sent: 
To: 
Cc: 



Subject: 



I think this is the result of Tim doing a top-level release of euterpe. 
It died trying to abstract the baseplate, because it couldn't find the 
layout files: 

padcrack_uplay. ly 
padseal_uplay . ly 
padm . ly 

which are in proteus/compass/layouts, but haven't been released. I'm 
guessing vant's blanket release last night missed them because his cell 
list is newly out of date -- these cells were first created yesterday. 

Should I release them now? 

Potatoe Chip writes: 
From chip Fri Aug 11 23:19:34 1995 
Date: Fri, 11 Aug 1995 23:19:22-0700 
From: chip (Potatoe Chip) 

Message-Id: <199508120619 .XAA23071@staypuf t .microunity . com> 
To: doi, torn 

Subject: output of euterpe/.checkoutrc 

Fri Aug 11 22:56:49 PDT 1995 (chip. Fri, 11 Aug 1995 22:56:41 -0700) euterpe 
[Release BOM (V5.0) in euterpe (Fri Aug 11 22:56:49 PDT 1995)] 

Dir euterpe BOM 5.0 



1.2 
1.13 
1.4 
1.1 



. checkoutrc 
Makefile 
Makefile. defs 
Makefile. rules 



Dir 

1.9 

1.52 

1.1 

1.5 

3 .22 

1.8 

3.2 

1.45 

15.1 

5.10 

1.29 

1.5 

1.3 



euterpe/baseplate 

. checkoutrc 

Makefile 

clean_reguest 

clockparms .m4 

custom. pif 

e c l_cutout . sgen . m4 

f loorplan.pif 

f loorplan. sgen.m4 

membrane. 1st 

mos_cutout . sgen . m4 

padlist.lst 

padring . sgen . m4 

spacet rans . sgen . m4 



BOM 26.0 



Dir 
1.8 
1.28 
6.1 



euterpe/clockbias 
. checkoutrc 
Makefile 

clockbias . domains 



BOM 7.0 



Dir 
1.9 
1.8 
1.9 



euterpe/compass 
vlsi .boo-all 
vlsi.boo-dcell 
vlsi .boo- tapeout 



BOM 7.0 
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Dir 


euterpe/ compass/layouts 


1.1 


. checkoutrc 


1.2 


Makefile 


5.5 


euterpe-hwc . ly 


1.4 


euterpe. db 


2 . 3 


euterpelpadtl . ly 


2.2 


euterpelpadtr . ly 


10 . 9 


f 0007 . ly 


19. 3 


1:0007 fill ctpg.ly 


19.3 


f0007_fill ml . ly 


19. 3 


f 0007_f ill_m2 . ly 


19. 3 


f 0007_f ill_m3 . ly 


19. 3 


f 0007_f ill_m4 .ly 


19.3 


f 0007_f ill_vl2 . ly 


19 . 3 


f 0007 f ill_v23 . ly 


19 . 3 


£ 0 0 0 7 f i 1 l_v3 4 . ly 


19.3 


f 0007_f lll_v45 . ly 


10.1 


f0008 .ly 


2.5 


lid_euterpe_l . ly 


8.1 


lid euterpep l.ly 


11. 1 


locked- eel Is 


e. 2 


pllwl . ly 




pllw2 . ly 


12.2 


probe_template . ly 


8.2 


steuterpelpadtl . ly 


8.2 


steuterpelpadtr . ly 


4.11 


vdda_partition. ly 


1.4 


vlsi.atr 


2 .37 


vlsi.cko 


11.1 


vlsi.idx 


2.40 


vlsi . log 


Dir 


. euterpe/dcell 


1.5 


.checkoutrc 


1.42 


Makefile 


10.4 


auindx. dcell 


1.5 


cc. dcell 


3 . 6 


cdio.dcell 


1 .26 


cerberus . dcell 


1.9 


cj .dcell 


14 . 2 


ck_f gen. dcell 


1.2 


clean- request 


13 .2 


cp. dcell 


11 . 4 


ctio. dcell 


1.2 


dcelldefs.m4 


1.5 


dr. dcell 


1.2 


drio. dcell 


8 . 8 


es. dcell 


2 .20 


gt. dcell 


1.5 


he. dcell 


14 .1 


hz. dcell 


1 . 8 


if e. dcell 


10 . 3 


iorate. dcell 


1.7 


ig. dcell 


2 . 13 


It. dcell 


9.4 


mc. dcell 


10 . 6 


mst .dcell 


1 . 8 


nb. dcell 


13.4 


rg. dcell 


1.15 


rgxmit. dcell 


11 . 7 


sr .dcell 


1 . 19 


uu. dcell 






Dir 


euterpe/doc 


4 .11 


Makefile 


4 .39 


cerberus. mi f 
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12 .5 


chancre ' f 




c^prznt . doc 


19.6 


clock.mif 




ompu e g.c 


8 . 1 


prxnt . aoc 




enclxan.mif 




euterpe-microarch .book 


4 14 


euterpe -mxcroarchTOC . mi f 


125 


euterpe . doc 


4 24 


en s.mi 


16 8 


xront . mif 


4 22 


intro.mif 


4 36 


memory . mif 


4 *24 


opcodes. mif 


4 24 


pipeline . mif 


7 3 


print . doc 


4 .22 




1.1 


test. eg' 


19.2 


testerinit.html 


18.19 


verify.html 


4.21 


xlu.mif 



Dir euterpe/doc/debug 
1 • 1 DebugExample_bad . html 

1 . 1 DebugExamp 1 e_head . html 

1 . 1 DebugExample_llev . html 

1 . 1 DebugExample_llnav . html 

1.1 DebugExample_nav.html 
1-1 DebugExample_xcor.html 
1 . 4 EuterpeDebug . html 

EuterpeDebug_not_obv . html 
EuterpeDebug_obv . html 
EuterpeDebug__pipe . html 

1.4 Logfiles.html 

1 . 5 Simulator_conf iguration . mif 

1.2 likedriverlog_flds.html 
1.2 likedriverlog_nav.html 

likedriverlog_x.html 

Dir euterpe/gards 
1.8 . checkoutrc 

1.50 Makefile 

sclean- request 

euterpe/ged 
. checkoutrc 
Makefile 



euterpe/ged/rf bom 3.0 

Dir euterpe/ged/rf/rfereg B0M 3 Q 

1 • 2 spice .1.1 

1.2 spice. 1.2 
spice. 1.3 
spice. 1.4 
spice. 1.5 
spice_cn.l.l 
spice_cn.l.2 
spice_cn.l.3 
spice_cn.l.4 
spice_cn.l.5 

I Dir euterpe/ged/rf /rfereg/hspice BOM 3 0 

1.3 Makefile 
,1.3 rfereg.hdr 
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Dir 


euterpe/ ged/rf /rf ureg 


1.2 


spice .1.1 


1.2 


spice. 1.2 


1.2 


spice .1.3 




spice .1.4 


12 


spice .1.5 


1.2 


spice_cix.l.l 


1.2 


spice_cn .1.2 


1.2 


spice_cn .1.3 


1.3 


spice_cn.l.4 


1.2 


spice_cn .1.5 


Dir 


euterpe /ged/rf/ rf ureg/hspi 


1.2 


rf ureg . heir 


Dir 


euterpe/ged/ rf /sbreg 


1.2 


spice .1.1 


1.2 


spice .1.2 


1.2 


spice .1.3 




spice. 1.4 


12 


spice .1.5 


1.2 


spice_cn .1.1 


1.2 


spice_cn .1.2 


1.2 


spice_cn.l .3 


1.3 


spice cn . 1 . 4 


1.2 


spice_cn.l.5 


Dir 


euterpe/ged/rf /sbreg/hspice 


1.2 


sbreg . hdr 


Dir 


euterpe/misc 


1.1 


gards . Ctrl 


1.1 


gards . spn 


1.9 


gards. vrf 


1.1 


global .net 


Dir 


euterpe/tab 


1.1 


. checkoutrc 


1.4 


Makefile 


4.1 


README 


Dir 


euterpe/verify 


3.12 


Makefile 


4.2 


Makefile . cmp 


1.38 


Makefile. defs 


1.66 


Makefile. rules 


3.13 


Makerules . local 


3 .10 


status 


Dir 


euterpe /verify/config 


1.1 


cde . hdr 


1.1 


cdo.hdr 


1.1 


cerb . hdr 


4.1 


cerbrom.hdr 


1.1 


cie.hdr 


1.1 


cio.hdr 




config.hdr 


1.1 


ctd.hdr 


1.1 


cti.hdr 


1 . 2 


dram . hdr 


1.2 


i_euterpe_wrap .parm 


1.1 


rom . hdr 


Dir 


euterpe/verify/ include 


1.3 


. checkoutrc 


1.15 


Makefile 


10.19 


cerberus . h 
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clean- request 




1.35 


end.S 




14.5 


hold.S 




4.23 


physaddr . h 




18.2 


start. S 




Dir 


euterpe/verify/nasty 




1.1 


.checkoutrc 




2.1 


. cvsignore 




1.11 


Makefile 




1.2 


cachenasty . S 




1.2 


cachenasty2 . S 




1.2 


cachenasty3 . S 




1.2 


cachenasty4 . S 




1.5 


cachenastyS . S 




11.1 


cachenasty5_var_al_l . exe 




11.1 


cachenasty5_var_bl_l . exe 




11.1 


cachenasty5_var_cl_l . exe 




11.1 


cachenasty5_var_dl 1 . exe 




11.1 


cachenasty5_var_el_l . exe 




1.2 


cachesynchnasty . S 




1.6 . 


cachesynchnasty2 . S 




11.1 


cachesynchnasty2_var_al_l 


exe 


11.1 


cache synchnas ty2_var_bl_l 


exe 


11.1 


cache synchnas ty 2_var_c l_l 


exe 




cachesynchnasty 2 var dl 1 


exe 


11.1 


cachesynchnasty2 var el l.exe 


1.2 






3.4 


exintbash . S 




1.12 


hermnasty . S 




Dir 


euterpe/veri fy/perf 




1.1 


. checkoutrc 




1.3 


Makefile 




1.3 


cerbjperf . S 




1.1 


clean-request 






dcache_j>erf . S 




1.1 


dcachemiss_perf . s 




1.3 


dram_perf . S 




1.3 


hermes _perf .S 




1.3 


romjperf . S 




Dir 


euterpe/verify/random 




2.1 


. checkoutrc 




1.20 


Makefile 




2.1 


clean- request 




3.1 


exclude 




3.2 


exclude_all 




3.1 


exc lude_a 1 l_but_e 




3.1 


exclude_all_but_extract 




2.1 


exc lude_mul_and_ext rac t 




3.2 


exclude_nothing . 




3.2 


regdepend_rl001 . S 




3.1 


regdepend_r 1 1 2 2 . S 




3.2 


regdepend_rl578 . S 




3.1 


regdepend_rl63 9 . S 




3.2 


regdepend_rl742 . S 




3.1 


regdepend_rl7803 . S 




2.2 


regdepend rl794.S 




3.1 


regdepend_rl7972 . S 




3.1 


regdepend_rl8300 . S 




3.1 


regdepend_rl8469 . S 






regdepend_rl84 7 . S 




3.2 


regdepend_rl906 . S 




3.1 


regdepend_rl9204 . S 




3.1 


regdepend_rl9368 . S 




2.2 


regdepend_rl937 . S 
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3.1 regdepend_rl9537.S 

3.1 regdepend_rl9701.S 

3 . 1 regdepend_r 1 9 8 6 5 . S 

3.1 regdepend_r2057.S 

2 . 2 regdepend_r2 0 7 9 . S 
3 . 1 regdepend_r2 14 3 5 . S 
3.1 ■ regdepend_r21599.S 
3 . 1 regdepend_r 2 1 7 6 8 . S 
3.1 regdepend_r21932 .S 

3 . 1 r egdepend_r 2 2 0 9 6 . S 

2 . 2 regdepend_r 2 2 2 6 . S 

3 . 1 regdepend_r2 2 7 9 . S 

2 . 2 regdepend__r 2 3 68. S 
3 . 1 regdepend_r247S . S 
3 . 1 regdepend_r24 93 . S 
3 . 1 regdepend_r 2 5 5 4 7 . S 
3 . 1 regdepend_r 2 5 7 2 8 . S 
3 . l regdepend_r2 6 8 8 . S 
3 . 1 regdepend_r2 695 . S 
3 . 1 r egdepend_r 2 8 9 5 . S 
3 . 1 regdepend_r 3 0 64 , S 

3 . 1 regdepend_r 3 0 9 4 . S 

3 . 1 regdepend_r3 3 62 . S 

3.1 regdepend_r3561.S 

2 . 2 regdepend_r3 93 . S 
3 . 1 regdepend_r 3 95 7 . S 
3 . 1 regdepend_r4l57 . S 
3 . 1 regdepend_r4 3 5 6 . S 
3 . 1 regdepend_r4552 . S 
3.1 regdepend_r4752.s 
3.1 regdepend_r 4 9 5 1 . S 

3 . 1 regdepend_r5 1 52 . S 

2.2 regdepend_r521.S 
3 . 1 regdepend_r5352 . S 

3.1 regdepend_r5557.S 

2 . 2 regdepend_r5564 . s 
2 . 2 regdepend_r5712 . S 

3.1 regdepend_r5757 . s 

2 . 2 regdepend_r5854 . S 

3 . 1 r egdepend_r 5 9 5 7 . S 

2 . 2 r egdepend_r 5 9 9 6 . S 
2 . 2 regdepend_r6143 . S 

3.1 regdepend_r6152.S 

2 . 2 r egdepend_r 6 3 0 8 . S 

3 . 1 regdepend_r63 5 2 . S 

2 . 2 regdepend_r6450 . S 
2.2 regdepend_r656.S 
2.2 regdepend_r6597.S 
2.2 regdepend_r6739.S 
2.2 regdepend^eSSl.S^ 
2 . 2 regdepend__r 7 2 1 0 . S 
2 . 2 r egdepend_r 7 3 3 8 . S 
2.2 regdepend_r7495 .S 

3.1 regdepend_r754 .S 

2 . 2 regdepend_r7623 . S 
2 . 2 r egdepend_r7 7 5 1 . S 
2.2 regdepend_r786.S 
2.2 regdepend_r915.S 
2 . 12 status 

3.1 stgen_rl0803.s 

3.1 stgen_rl0987.S 

3.1 stgen_rll362.S 

3.1 stgen_rl3311.S 

3.1 stgen_rl6899.S 

3.1 stgen_rl7070.S 

|3.1 stgen_rl7235.S 

1 3.1 stgen_ri7405.s Exhibits 
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stgen_r22478 .S 
stgen_r29924.S 
stgen_r8191.S 
stgen_template 
template 

euterpe/verify/standalone BO m 5.0 

template 

euterpe/verify/standalone/au BOM 2 0 

. checkoutrc 
Makefile 
auadd.pl 
auaddi.pl 
auand . pi 
1.1 auandi.pl 
1.1 auandn.pl 
1 . 5 aubranch . pi 

1.3 aubrfshort.pl 
1.1 aubrshort.pl 
aucopyi.pl 
aulib.cpp 
aunand.pl 
1.1 aunandi.pl 
1.1 aunor.pl 
1.1 aunori.pl 
auor . pi 
auori.pl 
auorn . pi 
aurandom . pi 
aushli.pl 
aushort.pl 
1.1 aushri.pl 
l.l aushrui.pl 
1.1 ausub.pl 
1.1 ausubi.pl 
1.3 autest.pl 
1.1 auxnor.pl 
r.pl 
..pi 



euterpe/verify/standalone/ce 
. checkoutrc 
Makefile 
ce. srl 

ce_debug . srl 
ce_defaults.S 
ce_def aults . loop 
ce_defaults.pl 
ce_defer.pl 

ce_norom.pl 
ce_rom . S 
ce_rom.pl 
clean-request 
testlib.pl 

euterpe/verify/standalone/dp 
. checkoutrc 
Makefile 
chkmatch 
clean- request 
dpeSmuxspc . test 
dpeadd.test 
dpeaddi . test 
dpeaddio . test 
dpeaddiospc . test 
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2 


dpeaddispc . test 




dpeaddiuo . test 




dpeaddiuospc . test 




dpeaddo . test 


2 1 


dpeaddospc. test 




dpeaddspc . test 


2 1 


dpeadduo .test 


2 1 


pead uospc . test 


12 


dpeand. test 


12 


dpeandi. . test 




dpeandispc . test 




dpeandn .test 




dpeandnspc . test 




dpeandspc . test 


12 


dpeasum. test 




dpeoande .test 




dpebandespc . test 


1 o 


dpebandne . test 




dpebandnespc . test 




dpebe . test 


•31 


dpebespc . test 


1.3 


dpebge . test 


12.1 


dpebgespc . test 




dpebl . test 




dpeblspc . test 


1.2 


dpebne . test 




dpebnespc . test 


• 3 


dpebuge . test 




dpebugespc . test 




dpebul . test 


1 O 1 


dpebulspc . test 


7 . 1 


dpecopyswapispc . test 


"l " 2 


dpedepispc . test 




dpedepixspc . test 




dpeeasumspc . test 




dpelgcshort . test 




dpelms . test 




dpelmsspc . test 




dpeindepispc . test 


17 .2 


dpemdepixspc . test 




dpemshr . test 


2 . 1 


dpenisliiri . test 


' 2 


dpemshrispc . test 


* 2 


dpemshrspc . test 


* ^ 


dpemux . test 




dpeiwuxspc . test 




dpenand . test 


12 


dpenandi . test 




dpenandispc . test 




dpenandspc . test 




dpenor . test 




dpenori . test 




dpenorxspc . test 




dpenorspc . test 


9 


dpeox - . test 




dpeori . test 




dpeorispc . test 


1 o 


dpeorn . test 


19 


dpeoirnspc . test 




dpeox"spc . test 




dperotl . test 


4 1 


dperotlspc . test 


2.1 


dperotr . test 


2.1 


dperotri . test 


4.1 


dperotrispc . test 


4.1 


dperotrspc . test 


7.1 


dpeselect8spc.test 
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! dpesete. test 

! dpesetespc . test 

! dpesetge . test 

! dpesetgespc . test 

( dpesetie . test 

2.1 dpesetiespc.test 

1 . 2 dpesetige . test 

2 . 1 dpesetigespc . test 

1.2 dpesetil.test 
dpesetilspc . test 
dpesetine . test 
dpesetinespc . test 
dpesetiuge . test 
dpesetiugespc . test 
dpesetiul . test 
dpesetiulspc . test 
dpesetl . test 

1.2 dpesetlspc.test 
1 . 2 dpesetne . test 

1.2 dpesetnespc . test 

1 . 3 dpesetshort . test 
1 . 2 dpesetuge . test 
1.2 dpesetugespc . test 
1 . 2 dpesetul . test 
1.2 dpesetulspc.test 
7^1 dpesf li4mxspc . test 

1 dpesf lxspc. test 

dpeshf tshort . test 
dpeshl . test 
dpeshli . test 
dpeshlio.test 
dpeshliospc.test 
dpeshlispc.test . 
dpeshl iuo .test 
dpeshliuospc . test 
dpeshlo.test 
dpeshlospc . test 
dpeshlspc.test 
dpeshluo. test 

2.1 dpeshluospc.test 

1.2 dpeshr.test 
1.2 dpeshri.test 

dpeshrispc . test 
dpeshrspc . test 

7.1 dpeshuf f leispc . test 

1.2 dpesub.test 
1.2 dpesube.test 

2.1 dpesubespc.test 
dpesubge . test 
dpesubgespc .test 
dpesubi . test 
dpesubie . test 
dpesubiespc . test 

1 . 2 dpesubige . test 

2 . 1 dpesubigespc . test 

1 . 2 dpesubil . test 
dpesubilspc. test 
dpesubine . test 
dpesubinespc .test 
dpesubio.test 
dpesubiospc . test 
dpesubi spc . test 
dpesubiuge . test 
dpesubiugespc . test 
dpesubiul .test 
dpesubiulspc . test 
dpesubiuo . test 
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2 . 1 dpesubiuospc . test 

1.2 dpesubl . test 

2 . 1 dpesublspc . test 

1.2 dpesubne.test 
2.1 dpesubnespc . test 
2 . 1 dpesubo . test 
2.1 dpesubospc.test 
1 . 4 dpesubshort . test 

2.1 dpesubspc . test 

1.2 dpesubuge. test 

2 . 1 dpesubugespc . test 

1 . 2 dpesubul . test 

2.1 dpesubulspc . test 

2.1 dpesubuo. test 

2.1 dpesubuospc . test 

7 . 1 dpetr8muxspc . test 

7 . 2 dpeudepispc . test 
17.2 dpeudepixspc . test 

2 . 1 dpeulms . test 

12 . 1 dpeulrasspc . test 

1 . 2 dpeushr . test 
1 . 2 dpeushri . test 

2 . 2 dpeushrispc . test 

2.2 dpeushrspc.test 

7 . 2 dpeuwthispc . test 

17 . 2 dpeuwthixspc . test 
7.2 dpewthispc.test 
17 . 2 dpewthixspc . test 
12.1 dpexlushort . test 
1.2 dpexnor.test 

1 . 2 dpexnorspc . test 

1.2 dpexor.test 

1.2 dpexori . test 

2.1 dpexorispc . test 

1 . 2 dpexorspc . test ( 
7.1 dpgSmuxspc .test 

1.3 dpgadd.test 

2.1 dpgaddspcl6.test 

2.1 dpgaddspc32.test 

2 . 1 dpgaddspc4 . test 

2.1 dpgaddspc64.test 

2 . 1 dpgaddspc 8 . t e s t 

1.2 dpgand.test 
1.2 dpgandn.test 
2.1 dpgandnspc . test 
2 . 1 dpgandspc . test 

4.1 dpgcmpshortspc.test 

2 . 2 dpgcompress . test 
2 . 2 dpgcompressi . test 
2.1 dpgcompressispcl.test 
2 . 1 dpgcompressispcl6 . test 
2.1 dpgcompressispc2 .test 
2.1 dpgcompressispc32 .test 
2.1 dpgcompressispc4 . test 
2.1 dpgcompressispc64 .test 
2.1 dpgcompressispc8 .test 
2 . 1 dpgcompressspcl . test 

2 . 1 dpgcompressspcl6 . test 

2 . 1 dpgcompressspc2 . test 

2.1 dpgcompressspc32 . test 

2.1 dpgcompressspc4 . test 

2 . 1 dpgcompressspc64 . test 

2 . 1 dpgcompressspc8 . test 

7 . 1 dpgcopys wapcpi spc . test 

7.1 dpgcopyswapispc. test 

7.1 dpgcopyswapswispc.test 

7.2 dpgdepispc.test 
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17 . 2 dpgdepixspc . test 

2 . 2 dpgexpand . test 

2 . 2 dpgexpandi . test 

2 . 1 dpgexpandispcl . test 

2.1 dpgexpandispcl6 . test 

2 . 1 dpgexpandispc2 . test 

2.1 dpgexpandi spc32. test 

2.1 dpgexpandi spc4 .test 

2.1 dpgexpandi spc64 . test 

2.1 dpgexpandispcS.test 

2 . 1 dpgexpandspcl . test 

2 . 2 dpgexpandspclS . test 
2 . 1 dpgexpandspc2 .test 
2.1 dpgexpandspc32 .test 
2 . 1 dpgexpandspc4 . test 
2.1 dpgexpandspcS4.test 
2.1 dpgexpandspc8 .test 

4.1 dpgexpshortspc.test 
. 12.1 dpgextractispc.test 

12 . 1 dpgextractispcl28 . test 

12.1 dpgextractispc64.test 

12 . 2 dpgextractspcl28 . test 
17 . 1 dpggf mul8spc . test 
12.1 dpgkarzexpe . test 

12 . 1 dpgkarzext2 .test 

12 . 1 dpgkarzext3 . test 

7.3 dpgmdepispc.test 

17 . 2 dpgmdepixspc . test 

2.2 dpgmshr.test 
2 . 2 dpgmshri . test 

4.1 dpgmshrispcl28.test 

4.1 dpgmshrispcie.test 

4 . 1 dpgmshrispc2 . test 

, 4 . 1 dpgmshrispc32 .test 

j 4 . 1 dpgmshrispc4 . test 

4 . 1 dpgmshrispc64 . test 

4 . 1 dpgmshrispc8 . test 

4.1 dpgmshrspcl28.test 

4.1 dpgmshrspcl6.test 

4 . 1 dpgmshrspc2 . test 

4 . 1 dpgmshrspc3 2 . test 

4 . 1 dpgmshrspc4 . test 

4 . 1 dpgmshrspc64 . test 

4 . 1 dpgmshrspc8 . test 

1 . 4 dpgmul . test 

1.2 dpgmuladdl6.test 
1.1 dpgmuladd32.test 

1 . 1 dpgmuladd4 . test 

1 . 2 dpgmuladd64 . test 
1 . 1 dpgmuladd8 . test 
1.1 dpgmuladspcl6 . test 
1.1 dpgmuladspc32 .test 
1.1 dpgmuladspc4 . test 
1 . 1 dpgrauladspc64 . test 

1.1 dpgrauladspc8.test 

2.2 dpgmulshort.test 
1.2 dpgmul spc 16. test 
1.2 dpgmulspc32 . test 
1.2 dpgmulspc4 . test 
1.2 dpgmulspc64 . test 
1.2 dpgmulspcS.test 
1.2 dpgmux.test 

2 . 1 dpgmuxspc . test 

1 . 2 dpgnand .test 
'2.1 dpgnandspc.test 
1 1 . 2 dpgnor . test 

j 2.1 dpgnorspc.test 
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1.2 dpgor . test 

1 . 2 dpgom .test 

2 . 1 dpgprnspc .test 

2 . 1 dpgorspc . test 

2 . 2 dpgrotl . test 

4.1 dpgrotlspcl28 .test 

4.1 dpgrotlspcl6.test 

4 . 1 dpgrotlspc2 . test 

4.1 dpgrotlspc32 .test 

4 . 1 dpgrotlspc4 . test 

4 .1 dpgrotlspc64 . test 

4.1 dpgrotlspcS.test 

2.2 dpgrotr.test 

2 . 2 dpgrotri . test 

4.1 dpgrotrispcl28.test 

4.1 dpgrotrispcl6.test 

4.1 dpgrotrispc2 . test 

4.1 dpgrotrispc32.test 

4 . 1 dpgrotrispc4 . test 

4.1 dpgrotrispc64 .test 

4.1 dpgrotrispc8 .test 

4.1 dpgrotrspcl28 .test 

4 . 1 dpgrotrspclS . test 

4 . 1 dpgrotrspc2 . test 

4.1 dpgrotrspc32 .test 

4 . 1 dpgrotrspc4 . test 

4 . 1 dpgrotrspc64 . test 

4.1 dpgrotrspcS . test 

7.1 dpgselect8spc. test 

1 . 3 dpgsete . test 

1.2 dpgsetespcl6 . test 
1.2 dpgsetespc32 .test 
1 . 2 dpgsetespc4 . test 
1 . 2 dpgsetespc64 . test 
1.2 dpgsetespc8 . test 
1.2 dpgsetge.test 

1.1 dpgsetgespclS . test 

l.l dpgsetgespc32 .test 

1 . 1 dpgsetgespc4 . test 

1 . 1 dpgsetgespc64 . test 

1 . 1 dpgsetgespc8 . test 

1.2 dpgsetl.test 

1.1 dpgsetlspcl6.test 

1.1 dpgsetlspc32 . test 

1.1 dpgsetlspc4 .test 

1.1 dpgsetlspc64 . test 

1.1 dpgsetlspc8 .test 

1 . 3 dpgsetne . test 

1.2 dpgsetnespcie . test 
1.2 dpgsetnespc32 .test 
1 . 2 dpgsetnespc4 . test 
1.2 dpgsetnespc64 .test 
1.2 dpgsetnespc8 . test 
2.2 dpgset short. test 

1 . 2 dpgsetuge . test 

1.1 dpgsetugespclS . test 

1.1 dpgsetugespc32.test 

1 . 1 dpgsetugespc4 . test 

1.1 dpgsetugespc64 .test 

1.1 dpgsetugespc8 . test 

1 . 2 dpgsetul . test 

1.1 dpgsetulspcl6 . test 

1.1 dpgsetul spc3 2 . test 

1 . 1 dpgsetulspc4 . test 

1.1 dpgsetulspc64 . test 

1.1 dpgsetulspc8 .test 

7 . i dpgsf li4mxspc . test Exhibit 5.. 
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1 dpgsflxspc.test 

dpgshf tshort . test 
i dpgshl . test 

! dpgshl i .test 

dpgshlispcl28 . test 
; dpgshlispcl6 . test 

dpgshlispc2 . test 
dpgshlispc32 . test 
dpgshlispc4 . test 
dpgshlispc64 . test 
dpgshlispc8 . test 
dpgshlspcl28 . test 
1.3 dpgshlspci6.test 
2 . 1 dpgshlspc2 . test 

1.3 dpgshlspc32.test 
dpgshlspc4 . test 
dpgshlspc64 . test 
dpgshlspc8 . test 
dpgshr.test 
dpgshri . test 
dpgshrispcl28 . test 
dpgshrispcl6 . test 
dpgshrispc2 . test 
dpgshrispc32 . test 
1 . 3 dpgshrispc4 . test 

1.3 dpgsb.rispc64.test 
1.3 dpgshri spc 8. test 

dpgshrspcl28 . test 
dpgshrspcl6 . test 
dpgshrspc2 . test 
dpgshrspc32 . test 
dpgshrspc4 . test 
dpgshrspc64 . test 
dpgshrspcS . test 
dpgshuf f leispc . test 
dpgsub.test 
dpgsubspcl6 . test 
dpgsubspc32 . test 
dpgsubspc4 . test 
2 . l dpgsubspc64 . test 

2 . 1 dpgsubspc8 . test 

7 . 1 dpgtrSmuxspc . test 

dpgucompress . test 
dpgucompressi . test 
dpgucompressispcl . test 
dpgucompressispcl6 . test 
dpgucompressispc2 . test 
dpgucompressispc32 . test 
dpgucompressispc4 .test 
dpgucompressi spc64 . test 
dpgucompressi spc 8 . test 
dpgucompressspcl . test 
dpgucompressspcl6 . test 
dpgucompressspc2 . test 
dpgucompressspc32 . test 
dpgucompressspc4 . test 
dpgucompress spc 54 .test 
dpgucompressspc8 . test 
dpgudepispc . test 
dpgudepixspc . test 
dpguexpand . test 
dpguexpandi .test 
dpguexpand! spc 1 . test 
dpguexpandispcie . test 
dpguexpandi spc2 . test 
dpguexpandispc32 . test 
dpguexpandispc4 . test 
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2 . 1 


dpguexpandispc64 . test 


2 . 1 


dpguexpandispcs . test 


2 .1 


dpguexpandspcl . test 


2 . 1 


dpguexpandspcie .test 


2 . 1 


dpguexpandspc2 .test 


2 . 1 


dpguexpandspc3 2 .test 


2 . 1 


dpguexpandspc4 . test 


2 . 1 


dpguexpandspc64 . test 


2 . 1 


dpguexpandspc8 . test 


12 .2 


dpguextractspcl28 . test 


1 . 3 


dpgumul . test 


1.1 


dpgumuladdie . test 


1.1 


dpgumuladd32 .test 


1 . 1 


dpgumuladd4 . test 


1 . 1 


dpgumuladd64 . test 


1.1 


dpgumuladd8 . test 


1.1 


dpgumuladspcl6 . test 


1.1 


dpgumuladspc32 . test 


1.1 


dpgumuladspc4 . test 


1 . 1 


dpgumuladspc64 .test 


1 . 1 


dpgumuladspcS . test 


1.2 


dpgumulspcl6 . test 


1.2 


dpgumul spc 3 2 .test 


1.2 


dpgumulspc4 . test 


1.2 


dpgumulspc64 .test 


1.2 


dpgumulspcS . test 


1.3 


dpgushr.test 


1 . 3 


dpgushri . test 


7 . 1 


dpgushrispcl28 . test 


1.3 


dpgushrispcl6 . test 


2 . 1 


dpgushrispc2 . test 


1.3 


dpgushrispc32 . test 


1 .3 


dpgushrispc4 . test 


1.3 


dpgushrispcS4 . test 


1.3 


dpgushrispc8 . test 


7 . 1 


dpgushrspcl2 8 . test 


1.3 


dpgushrspcl6 . test 


2.1 


dpgushrspc2 . test 


1.3 


dpgushrspc32 . test 


1.3 


dpgushrspc4 . test 


1 . 3 


dpgushrspc64 . test 


1.3 


dpgushrspcS . test 


7.2 


dpguwthispc . test 


17 .2 


dpguwthixspc . test 


7.2 


dpgwthispc.test . 


17.2 


dpgwthixspc . test 


12 .1 


dpgxlushort . test 


1.2 


dpgxnor.test 


2 . 1 


dpgxnorspc . test 


1.2 


dpgxor.test 


2.1 


dpgxorspc . test 


1.9 


genastn.pl 


1.7 


genmac.pl 


1.3 


genmacasm.pl 


6.2 


ios 


6 . 1 


loop. file 


1.11 


ntestmac.pl 


1.7 


parse_log . pi 


Dir 


euterpe/veri f y/standalone/dr 


1.1 


Makefile 


1 . 1 


dr.config.h 




drtester . V 


1.1 


drtester .h 


Dir 


euterpe/verify/standalone/ef 


1.1 


chkmatch 
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1.1 del_line 
1.1 efgfadd32 
1 . 1 ef gf sub32 

genasm.pl 
genmac . pi 
ntestmac.pl 

Dir euterpe/veri f y / standalone/ef / coonen 

1 . 1 c_f add 

1 . 1 c_f mal 

1 . 1 c_f ma2 

1 . 1 c_f ma3 

1.1 c_fmsl 
1 . 1 c_f ms2 

c_fraul 
c_f sub 

euterpe/verify/standalone/el 
Makefile 
chkmatch 
del_line 
elgfaddl6 
elgfmull6 
1.1 elgfmuladdl6 

1.1 elgfraulsubl6 

1.2 elgfshortlS 
1.1 elgfsublS 

1 . 1 genasm . pi 

1.2 ntestraac.pl 

Dir euterpe/verify/standalone/el/coonen 
1.1 c_fadd 
1.1 . c_fmal 
1.1 c „fma2 
1.1 c_f ma3 

1.1 c_fmsl 
c_fms2 
c_fmul 
c_f sub 

euterpe/verify/ standalone/em 
Makefile 
chkmatch 
del_line 
emeexpand 

1 . 2 emeshl 
1.2 emeshli 

1 . 2 emeshort 
emeshr 
emeshri 
emeushr 
emeushri 
emgcompress 
emgcompressi 
emgcopy 
emgdeal 
emgexpand 
emgexpandi 
eragshl 
emgshli 
emgshort 
emgshr 
emgshri 
emgshuf f le 

1.3 emgswap 

i 1 . 3 emguexpand 

|1.3 emguexpandi 5 
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1.3 


emgushr 


1.3 


eragushri 


1.3 


genasm . pi 


1.3 


ntestmac . pi 


Dir 


euterpe/verify/standalone/et 


1.1 


. checkoutrc 


1.1 


Makefile 


Dir 


euterpe/verify/standalone/hc 


1.37 


Makefile 


1.24 


NOTES 


8.5 


addrhex_gen . c 


8.1 


addroct_gen . c 


5.1 


addrs . h 


1.2 


btob.vec 


2.4 


btob2 . vec 


8.1 


btobstomp.vec 


7.1 


bug3_gen . c 


1.1 


bwfast_gen.c 


8 .1 


checkresults 


7.11 


clkregress.pl 


8.1 


config.file 


8.4 


conflict2.pl 


2.1 


conf lict_gen.c 


5.2 


event .pi 


5.7 


evnt8 .vec 


5.3 


evnt8mix_gen. c 


5.1 


evnthex.vec 


5.2 


evntrd.vec 


7.2 


fillfifo.pl 


8.1 


gaunt let. vec 


2.1 


hc.h 


1.1 


hcO_laddr.vec 


1.1 


hcl_2addr . vec 


1.8 


hc_device. V 


2.9 


hc_drive . V 


2.1 


hc_dri ve . h 


2.2 


hc_periph. V 


4.4 


hcregress 


8.2 


hex3 stor_gen . c 


5.1 


hexratio_gen . c 


8.1 


hiaddr . vec 


5.2 


hi cup. vec 


5.1 


ileave2xl_gen . c 


5.4 


i Ieave2x2_gen . c 


5 . 1 


ileave2x4_gen . c 


8 . 1 


lateenbl.pl 


2.3 


lg.vec 


4.5 


1 grant .vec 


8.1 


lisabug.vec 


2.3 


multspace_gen . c 


1.3 


nb.h 


8.3 


nb_jpri_S . vec 


1.47 


nbhc_drive.v 


1.7 


nbhc_drive . h 


5.12 


nbhcregress 


5.1 


octhex_gen.c 


2 . 2 


onechan.vec 


7.3 


parseout 


8.1 


perf _dr_hi_gen . C 


8.1 


perf_gen.c 






8.2 


simphex. vec 


8.2 


startup.pl 


8.2 


stomp. vec 


8.6 


stompratio_gen . c 
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5.2 sustain. vec 

1 . 1 twochan_gen . c 

5.4 - vectools.c 
1.1 xfilt.awk 



euterpe/verify/standalone/hcpll 
. checkoutrc 
Makefile 
clean- request 
hcpll.pl 

euterpe/verify/standalone/ife 
. checkoutrc 
2 Makefile 

brhextest . S 

1 . 6 brimmbktest . s 

2 . 2 brimmlongtest . S 

1 - 6 brimmtest . S 

1.7 brpctest.S 
brpctest2.S 
brpipetest . S 

1.4 brpipetest2 . S 

1 - 4 brpipetest3 . S 

1 . 4 brpipetest4 . S 

1 . 4 brpipetestS . S 

1.5 brregtest.S 
clean- request 



(Attic) 
(Attic) 
(Attic) 
(Attic) 
(Attic) 
(Attic) 
(Attic) 
(Attic) 
(Attic) 
(Attic) 
(Attic) 
(Attic) 



Dir 


cuLerpe/verity/ stancialone/io 


1.5 


Makefile 


1.2 


NOTES 


1.1 


clkgen. V 


1.1 


equaldrive . V 


1.1 


iobyte .V 


1.1 


skewer. V 


1.1 


tester .V 


1.14 


verdrive.V 


1.4 


verilog . log . gz 


Dir 


euterpe/verify/standalone/ld 


l.l 


. checkoutrc 


1.24 


Makefile 


8.2 


branch.pl 


8.5 


clean- request 


1.7 


ldaops.pl 


10.1 


ldcarry.pl 


13.1 


ldrandom.pl 


1.5 


ldshift.pl 


1.3 


ldshort.pl 


13.1 


randotnbranch . pi 


11.2 


randomshift.pl 


13.1 


shell. s 


Dir 


euterpe/verify/standalone/nb 


1.10 


Makefile 


1.11 


NOTES 


1.5 


TESTS . doc 


1.2 


bw_gen . c 


1.1 


dr_pri_l . vec 


1.1 


drjpri_gen.c 


1.1 


hex3 chan_l 6_gen . c 


1.1 


hex3 chan_8_gen . c 


1.1 


hex3 stor_gen . c 


1.1 


hexratio_gen . c 


1.2 


hratiol_gen.c 


1.3 


multild. vec 


1.1 


nb.h 
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nb . toplevel . ut 




11 








no drive. V 




1 ' 1 


nb_drive.bak 




11 


nb_driye.h. 




r ' 


oneld__lo gen.c 






oneld 8 gen.c 






periph.v 




l.i 


penph . new 






regress 




li 






1.1 


threechan_gen. c 




1.3 


twochan.vec 




1 . 2 


twochan_gen . c 




1.2 


vecgen 


(Attic) 


1.7 


vecgen. c 




. 


euterpe/ verify/ standalone/uu 


BOM 17.0 




. checkoutrc 






. cvs ignore 




i 


Makefile 




O "7 


bback . S 


(Attic) 


fi7 




(Attic) 


6.2 


blink. S 


(Attic) 


8.5 


cerbrupttest . S 


(Attic) 




clean- request 


■7 f 


exlOtest . S 


(Attic) 




exlOtest V.ginat 




■ 


exlotesfc_V.gmsk 




7.2 


exlOtest V.gxor 




7.4 


exlltest . S 


(Attic) 


10 . 1 


exlltest2 . S 


(Attic) 


8 . 5 


exl5test.S 


(Attic) 


n 3 


ex9test . S 


(Attic) 


' 


ex9test_V . gmat 




" I" 


ex9test_V. gmsk 




7 . 1 


ex9test_V.gxor 




6.4 


exaligneasy .S 


(Attic) 


6.4 


exalignharder . S 


(Attic) 




exaligntest . S 


(Attic) 


2.2 


exf ixeasy.S 


(Attic) 




exf ixbandler . S 


(Attic) 


6.4 


exgenhandler . s 


(Attic) 


3.1 


exhandler . S 


(Attic) 


8.4 


exlocktest . S 


(Attic) 


2.6 


exmaskeasy . S 


(Attic) 




exmasktest . S 


(Attic) 


9 11 


extnaskfcest2 . s 


(Attic) 




exmasktest3 . S 


(Attic) 




extnasktest4 . S 


(Attic) 


2 . 6 


exmasktests . S 


(Attic) 




exopaligneasy . S 


(Attic) 


iv 


expetest . S 


"(Attic) 




exrleasy . S 


(Attic) 




exregeasy . S 


(Attic) 




exresbminortest . S 


(Attic) 


c ' 
o ' c 


exrescruel . S 


(Attic) 




exreseasy.S 


(Attic) 


Q ' 1 


exresedepitestl . S 


(Attic) 


3 ' 1 

■ r - 


exresedepitest2 . S 


(Attic) 




exresemdepitestl . S 


(Attic) 


3 ' 1 


exresemdepitest2 . S 


(Attic) 


2.6 


exreseminortest . S 




8.1 


exreseudepitestl . S 


(Attic) 


8.1 


exreseudepitest2 . S 


(Attic) 


8.1 


exreseuwthitestl . S 


(Attic) 


8.1 


exreseuwthitest2 . S 


(Attic) 
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11.1 
11.1 

12.1 



8.1 
8.1 
8.1 
8.1 
8.1 



2.3 

2.4 

2.7 

6.6 

2.5 

2.11 

2.8 

2.10 

8.4 

8.2 

1.6 

2.2 

2.18 

1.4 



1.4 

1.15 

1.25 



1.10 

1.2 

1.1 



exresewthitestl . S 
exresewthitest2 . S 
exresg_12 8test . S 
exresg_16test . S 
exresg_ltest . S 
exresg_2test . S 
exresg_32test . S 
exresg_4test . S 
exresg_64test . S 
exresg_8test . S 
exresgcmpritestl . S 
exresgdepitestl . S 
exresgdepitest2 . S 
exresgexpitestl . s 
exresgmdepitestl . S 
exresgmdepitest2 . s 
exresgmshritestl . S 
exresgrotritestl . S 
exresgshlitestl . S 
exresgshritestl . S 
exresgucmpritestl . S 
exresgudepitestl . S 
exresgudepitest2 . S 
exresguexpitestl . S 
exresgushritestl . S 
exresguwthitestl . S 
exresguwthitest2 . S 
exresgwthitestl . S 
exresgwthitest2 . S 
exreshandler.S 
exreslminortest . S 
exresma j or . S 
exresregeasy.S 
exressminortest . S 
extimertest . S 
extimertest2 . S 
privnumtest . S 
ruptpintest . S 
ruptpintest . sen 
thcylnumtest . S 
thcylnuratest2 . S 
thexheader . S 
thheader.S 

euterpe/verify/tools 
cmpregcommit 



levelcommit 
likelevellbg 
mergesections 
parsecotnmit 
• parselikedriver 
sdram2regs 
stbash 
stgen 

euterpe/verify/tools/el 

. checkoutrc 

Makefile 

apd2macl . c 

apd2resl . c 

chk_res . c 

chkans . c 

chksdq.c 

filestuff .h 

fp.h 

fpsdg. c 



(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 

(Attic) 
(Attic) 
(Attic) 
(Attic) 
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1.1 fpsdq.h 

1.2 h2doll.c 
1.1 hex2dollar.c 
6.4 karztest.c 
1.1 libapd.a 

libapd.h 
libsdq.a 
mak.lib 
mydecls.h 
8 newchkans . c 
0 opdrvr . c 

opgen . c 
opgen . h 
sdq . c 
sdq.h 

splitnshift.pl 
splitnshif tf lags .pi 
ver_fl.c 

euterpe/verify/tools/ld 

0 aopslib.cpp 
bigext . cpp 
eugen.pl 

1 eulib.cpp 
1 ocandromld 

4 . 10 oconlyld 

1.1 pad.pl 
19.2 realld 

1 . 2 unpad . pi 

Dir euterpe/verify/tools/regdepend 
1.1 . checkoutrc 

1.4 Makefile 
1.29 regdepend.c 

Dir euterpe/verify/toplevel 
. checkoutrc 
I .cvs ignore 

'1 Makefile 
! addrsplusS.S 
! bdownharder . S 

branch. S 
i brcrosstest.S 
30.1 brhermes.S 
31.1 brhermesshort . s 
3 5.1 brimmlongtest . S 

brimmlongtest2 . S 
brmisseasy.S 
brmisseasy.cti 
brmisstest.S 
brmisstest.cti 
brpcrupt . S 
brpcrupt2 . S 
brpcrupt 3 .S 
brpcrupt3 . cti 
cache . m 
cache_V.m 
cache_debug . sig 
cachesyncheasy . S 
cd_debug. srl 
cerb_registers . S 
cerbarbdatatest . S 
cerbcache.S 
cerbconfig.S 
cerbeasy.S 
cerberrtest.S 

cerberus.S „ . . 
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40.1 


cerbillresp . S 


12 .2 


cerbload . S 


40 . 1 




22.4 


cerbraw 6 ^ S 


32.1 


cerbraweasy . S 


24.3 


cerbstartfcest S 


34.1 


cerbtorom , S 


39.2 


cerbtotest . S 


7.6 


clear ^ eC * UeSfc 


7 .4 






clear o . loop 


33 .2 




32 .1 


collision debug. srl 


30.2 


commit . sig 


24 .3 


commit . srl 


24 . 3 


conf igl . ni 


27 . 1 




5.1 


crcolaut d b 

gu s_ ecug.srl 




C3ruptn.a3ra.e3r . S 


30 . 1 


cruptharder . cfci 


11.3 


cystoreload . S 


39. 1 


dcache 6 ™ 11 ^ " S ^ 


15.3 




23 . 8 


dcachea 


33 .3 


dcachearm ? 


11. 13 




11 .2 


. , y.cta 




Qcacneeasy . cti 


18 1 


dcacheeasy v.gmat 


18 1 


dcacheeasy V.gmsk 


18 1 


dcacheeasy V.gxor 


15 10 


dcacheharder . S 


31 4 


u.cacneriaraeir2 . S r 


31.1 


dcacheharder2 V.gntat 




dcacheharder2__V. gmsk 


31.1 


dcacheharder2 V.gxor 




dcacheharder3 . S 


311 


dcacheharder3 V. gmat 


311 


dcacheharder3 V. gmsk 


311 


dcacheharder 3 V.gxor 


31.4 


dcacheharder4 . S 


33 .3 


ac e araer5 . S 


33 . 2 




35 . 2 






dcacnexiaroerS . S 


18 1 


dcacheharder_V . gmat 


18 . 1 


dcacheharder V.gmsk 




dcacheharder V . gxor 


31.3 


dcachenoalloc . s 


31.1 


cac enoa loc . ctd 


15 .1 


e au . eta 




aetault . ctx 


15.3 


default . gmat 




default . gmsk 


15 . 3 


default . gxor 






26.2 


defer 0 1 




d fc>1~ t- Ih 


33 . 1 


doubleextest2 S 


26.5 


doublemctest . S 


39.2 


dr debug. sig 


7.8 


dram . S 


7.5 


dram . m 


27.1 


dram_conf igO . conf ig 


27.1 


dram_conf igl . conf ig 


7.4 


dram_debug . srl 


7.7 


drameasy . S 
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31.4 


dratnex . S 


7 . 5 




11.4 


dramload . S 


35.1 


drampartial . S 


11.3 


dramprint . S 






33.3 


dramprintharder2 . S 




dt ag_debug . s i g 


24 1 


e h rt S eeaS "*'" 


' 7 4 




33 1 


eu config 


33 .1 


eu. ctd 






26 3 


eu f 


2 3 




33 1 


. oop 


2 3 




27.1 


eu ' si" 


2 . 6 


eu ' srl 


25.3 


eu . vec 


2Q 1 1 


eu_barrelO . srl 




ug.sig 


5 9 




26 


evencdaemoneasy . S 


26 6 




35*4 


exlltest3 S 


35 . 6 


exlltest4 . S 


35 .1 


exhancache.S 




exmas a omic.S 


35*2 




35.3 


frz debu ' 


32.1 


qqfmulde S 


7.8 


qtlb S 




atlbaccessl S 




ctlbacc IV 


22 . 1 


tlb i~ v v 


22 . 1 


tlbaccessl - V S 




gtlbaccess2~S ' 9X ° r 


22 . 1 


gtlbaccess2 V groat 


22 . 1 


gtlbaccess2 V.gtnsk 




^^ aCCeSS ?-I' 3XOr 


7 .14 




22 . 1 


tlbac B gs3 v 


22 . 1 


tlbacce S3 - V k 


22 . 1 


tlbacces 3~ V 


26 . 4 


qtlbaccess4~ S ^ X ° r 


26 . 1 


qtlbaccess4 V 


26 . 1 


tlbaccess4~ v'^^k 


26 . 1 


qtlbacce s4~ V 


7 . 5 


qtlbeas" 2 " 3 ^ — "^ X ° r 


7 . 13 


qtlbm' 

3 isseasy. 




gt-Lbnusseasy V . groat 


22 1 


gtlbroi sseasy V . grosk 


22 ' 1 




39 " 1 


heldbac^debug " sig"" 


7.8 


hermes . S 






351 


hermes _ I2 " S 


35 . 2 


hermes - 14 S 




hermes - I store uni 


35.3 


hermes Ibash . S 


7.9 


hermes debug, srl 


2.1 


hermes_idles . loop 


32.1 


hermes_lateturnon. S 


8.7 


hermeseasy.S 


35.2 


hermeseasy_HMO . S 


33.1 


hermesbarder.S 
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32 .3 


hermesload S 


35.2 


hermesmc . S 


35.1 


bermesinc . Iiconf ig 


39.3 




39.2 


hermtotest^S^ U3 ' 


39.1 


hermtotest . hconf ig 


14.2 




39.2 


ibufbz debug. srl 


33 .2 


icaclie4k . S 


26.6 


icacheannoying . S 


28.1 




18.9 


. , eas Y- 


16.4 


• a ° eeas y- ct:L 


16.2 


-Lcaoneeasy_V. gmafc 


16.2 


zcacheeasy V.gmsk 


16 . 2 


xcacheeasy_V. gxor 




lcacnenarder . S 


23 1 


icacbeharder . cfci 


33 .2 


icacheharder2 . s 


33 . 3 


icaciienarder3 . S 


18.1 


icacbeinifc . s 


27 . 6 




27.1 


icach em ^ SS " S f- 1 


33 .4 




35.2 


if e^^h"** ° C " 


39.1 


ife _ debu 9 ' S1 l 


35.2 


if ill deb' 

— ug.sig 




lorupttest . S 


37.2 


isotest . S 




itag_storeeasy . S 


8 . 6 


knobha S d' S 


8 . 6 


ar er.S 




latedxrty . S 




lbranch . pi 


27 


likedriverlog. sig 


7 12 


likedriverlog. srl 


6 . 12 


load.S 




loop . xile 


7.9 


ltlb.S 


19.1 


ltlbeasy.S 


35.2 


ltlbga.S 


33.3 


ltlbtran.S 


39.2 


lva_debug.sig 



4 0.2 mc_debug . sig 

6.4 memtest.S 

7.5 raeratesteasy.S 
3 9.2 nb_debug.srl 
11-2 nbfulltest.S 
35.2 nbhilotest.S 
31.2 nbhiprio.S 
31.1 nbhiprio_V . gmat 
31.1 nbhlprioJV . gmsk 

31.1 nbhiprio_V . gxor 

37.2 nbsmalltest . S 

2 6.3 nbuseeasy.S 

35.3 nbusemul.S 
33.2 ovfloaduse.S 
27.2 pagesize.S 

28.1 pages izeharder.S 

35.1 pll.lO.lO.S 

35.1 pll.S 

3 3.7 prblm_debug .sig 

35.2 preem_debug . sig 
19.1 prxv.S 

'39.1' readdaemon . S 

5 . 2 reg_barrelO_debug . srl 

| 5 . 1 reg_debug . srl 
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8.2 register. S 

8.2 rf.S 

24 . 2 romeasy . S 

24 . 3 romstarttest . S 
23.3 romtest.S 

30.2 saaseasy.S 

28.3 saastest.S 
6 . 2 save . S 

5 . 1 save . sen 
39.1 scasdep.S 
3 0.2 scaseasy.S 

30.3 scastest.S 

11.1 shell. S 

2 . 4 short . S 

33.4 snake_debug . s ig 

7 . 5 snoop . S 

7.5 store. S 

7.14 store_unique.S 

27.2 storeloadeasy . S 
26.2 synchtest.S 

32.1 tag_loadeasy . ctd 

35.2 tagaccess.S 
33.2 taghz_debug . sig 

I. 108 template 
2.8 testl.S 
8.4 testlO.S 

8.2 testll.S 
8.4 test!2.S 

II. 2 testl3 .S 
11.2 testl4.S 
25.1 testl5.S 
24.1 testl6.S 
2.12 test2.S 

2.6 test3.S 

5.7 test4.S 

5.8 tests. S 

5.8 test6.S 
5.10 test7.S 
5.6 test8.S 
8.2 test9.S 
2.2 tieoff.sen 

35.1 trgt_debug . sig 
3 0.2 uncrupt . S 

31.2 uncxrupt2.S 

30.3 uncruptharder . S 
5 . 1 uu2_debug . srl 

5.9 uu_debug.srl 
39.1 uunb_debug . srl 
33.3 vlduv_debug . sig 
7.8 watchtest.S 
33.9 wbck_debug . sig 

3 0.4 xresist.S 

Dir euterpe/verify/toplevel/hermes BOM 11.0 

1.1 .checkoutrc 

1.1 ..cvsignore 

1.2 Makefile 

3.1 clean-request 

1.8 hermestest.s 

1 . 1 hermestest . ctd 

1.1 hermestest. cti 

1.1 ' hermestest. gmat 

1 . 1 hermestest . gmsk 

1.1 hermestest . gxor 

Dir euterpe/verify/ukernel BOM 7.0 

1.1 . checkoutrc 
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1.10 



Makefile 



Dir euterpe/verilog 
1.1 . checkoutrc 

1.8 Makefile 

Dir euterpe/verilog/bsrc 
32.7 .checkoutrc 

73.1 lcesnk.ut 

116.1 ldr_basic.ut 

1.251 Makefile 

1.57 Makefile. share 

40.104 Makefile. tst - 

27.43 Makefile. vo 

6 8 ■ 5 a_euterpe_wrap . parm 

35.7 analog_euterpe . hwc 

183.8 c_euterpe_wrap . parm 

231.5 c_eut erpe_wrap . parm . al t 

312.20 chip_euterpe-base.netcap 

307.11 chip_euterpe-base.nof 

312.23 chip_euterpe -base. pirn 

312.20 chip_euterpe-base. strength 

307.11 chip_euterpe-base.xrf 



35 . 8 


clockbias.hwc 


168 . 1 


corridor. obs 


304 .14 


cust_intf .wkz 


68.3 


d_euterpe wrap. parm 


80.5 


dcells.pif 


7.1 


doexcldlist 


80 .1 


dummy. rcf 


308 .2 


e_mnemo_wrap . vhdl 


6 . 429 


euterpe.v 


12.6 


euterpe . conf ig 


24 . 77 


euterpe . status 


6 . 76 


euterpe_driver . V 


194 .1 


euterpe_known_problems 


6 . 31 


euterpe jpads . V 


15 4°° 


euterpe_wrap.V 




euterpe_wrap .parm 


134 .4 




119.4 


export~subblock 


20.1 


fake.pl 


284.2 


fence . srf 


280.1 


geert_v2e . conf ig 


41.20 


genpim2 .pi 


47.10 


gettst 


65.5 


h_euterpe_wrap . parm 


12.1 


hwcnets 


308.2 


i_euterpe_mnemo_wrap . tb 


187.14 


i_euterpe_wrap . tb 


187.13 


i_euterpe_wrap . vhdl 


325.4 


i_h_euterpe_wrap . tb 


325.3 


i_s_euterpe_wrap . tb 


91.6 


levellog 


134.2 


levelmlog 


1.18 


opchart 


168.8 


padtiles.ercf 


37.8 


pimlib.pl 


131.3 


preptest 


70.3 


purgetst 


131.1 


runs 


134.8 


runvtest 


240.2 


s_euterpe_wrap . parm 


62.10 


stashtst 


40.4 


subblk.rcf 


52.5 


tbr3_v2e.config 


35.3 


toplev .power . tab . local 
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41.5 toplev.rcf 
12.2 tst_y2e.config 



Dir euterpe/verilog/bsrc/at BOM 93.0 

4.2 . checkoutrc 

1.18 Makefile 
1.56 at.V 
1.7 at.h 
51.23 at.pim 

28.8 at. power. tab. top 

1.3 atcdwe2.pla 

59.1 atcteql2.V 

1 . 1 atcylenc . pla 
1.5 atdisallowxc .pla 

25 . 3 atgtlbcnf let .Veqn 
1.5 atgtmissxc.Veqn 

44.4 atillglpa. Veqn 

2 . 4 atnbreq . Veqn 
1.25 atpaded . Veqn 
1.3 atpaselgen64 .V 

66.2 atpaselgen8 . V 

1.19 atpr chk . Veqn 
1 . 3 atvabyp . Veqn 

1.5 atxceribl.pla 

1.2 atxcfrz.Veqn 

4.11 clean- request 

1.3 genatcteql58.pl 

1.1 genatpasel.pl 

3.12 genpim.pl 

3.2 genptab.pl 
3.9 pimlib.pl 

Dir euterpe/verilog/bsrc/au BOM 44 . 0 

14.2 .checkoutrc 
1.11 Makefile 
16.11 au. power. tab. top 
1.24 auindx.V 
12.11 auindx.pim 
14 . 8 clean- request 

12 . 5 genpim . pi 
12.1 pimlib.pl 
14.4 power . tab . local 

Dir euterpe/verilog/bsrc/cc 

9.3 . checkoutrc 
1.27 Makefile 
1.87 cc.V 
63.4 cc.flat.pim 

32.7 cc. power. tab. top 
1.18 cc.ut 

77.8 cc_control_blob . pirn 

73.3 cc_misc.pim 
78.1 c'c_pbb.pim 

28.6 cccount.pla 

80.1 ccf illcount.pla 
28.6 cchexcount.pla 
60.3 cchold.Veqn 
4 0.9 eclatedirty . Veqn 
51.10 ccrcv.Veqn 
28.20 ccseq.Veqn 
24.18 ccstart.Veqn 

77.2 ccstart_custom.pim 
1.21 cctester.V 
1.1 cctester.h 
14.13 clean-request 
5.20 genpim . pi 
5.16 pimlib.pl 
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5.2 power. tab. local 



Dir 

19.9 

1.12 

1.20 

34.10 

7.1 

28.5 



2.20 

2.19 

17.6 

17.4 

32.14 

2.10 

1.6 

1.24 

1.2 

1.4 

1.2 

1.9 

1.1 

1.14 

1.8 

'1.8 

1.58 

1.31 

1.4 

1.7 

1.6 

1.9 

1.44 

1.7 

1.43 

1.20 

1.5 

77.4 



Dir 
1.9 
9.1 

Dir 
46.5 



1.21 
1.3 
62.10 
69.12 
13.38 
\8. 8 
1.10 
|42.3 



euterpe/verilog/bsrc/cdio 
. checkoutrc 
Makefile 
cdio . V 

cdio . power . tab . top 
cdio.ut 

cdio_control .pim 
clean- request 
genpim.pl 
genptab.pl 
pimlib.pl 

euterpe/verilog/bsrc/ce 

Makefile 

Makefile . gards 

Makefile . irsim 

ce.config 

ce_cms2ecl . V 

ce_flash.v 

ce_kybd.V 

ce_kybdcntr . V 

ce_mck.V 

ce_seg7.V 

ceclockbiasbuf .V 

cecore.V 

cedmctrl. V 

cedmctrlm . V 

cedmctrlt.V 

cedpreg . V 

celoosends.V 

cemaster.v 

cerb . in 

cerbctrlreg.V 

cerberus . v 

Cerberus . cpif 

cerberus . rcf 

cerbnobreg . V 

cerbskewreg.V 

cerbtempreg . V 

cerbtest.V 

ceregbuf . V 

ceregcore. V 

ceslave.V 

cetstmux. V 

pimlib.pl 

euterpe/verilog/bsrc/cg 
Makefile 

cgclockbias . v. f or_use_with_squelsh_buf f er 

euterpe/verilog/bsrc/cj 

. checkoutrc 

libr.ut 

liss.ut 

Makefile 

br . tst 

brxcdef er . tst 
cj.V 
cj .h 
cj .pim 

c j . power . tab . top 
cjrst.tst 
clean- request 
f reel. tst 
genpim . pi 
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47 . 7 


genptab . pi 


11.20 


hie . tst 


1. 15 


hold.tst 


3 .19 


ifbr.tst 


23 . 8 


ifpred3-ll .tst 


20 . 7 


ifpred3-2 .tst 


5.26 


micbr.tst 


5.15 


pcbhnd.tst 


42 . 3 


piralib.pl 


78 . 12 


rsrvd. tst 


93 . 4 


rupt . tst 


Dir 


eut erpe /ver i log/ bsr c / ck 


10 .4 


. checkoutrc 


1.8 


Makefile 


l^S 


ck.V 




ck . power . tab . top 


1.3 


cktop.V 


11.1 


clean 


12 .2 


clean- request 


10.2 


genpim.pl 


10.5 


pimlib.pl 


Dir 


euterpe/verilog/bsrc/cp 


9.4 


. checkoutrc 


1 . 9 


Makefile 


9.9 


clean-request 


1.36 


cp.V 


7 . 14 


cp.pim 


19.12 


cp. power. tab. top 


41. 8 


cph.pim 


47.4 


cphh.pim 


41.7 


cpl.pim 


5 . 11 


genpim . pi 


5.4 


pimlib.pl 


5.15 


power . tab . local 


Dir 


euterpe/verilog/bsrc/ctiod 


1.4 


. checkoutrc 


1.6 


Makefile 


7 . 1 


bram. init 


1.7 


clean-request 


7.1 


ctd. in 


1.11 


ctiod.V 


12 . 8 


ctiod. power . tab . top 


6.3 


ctiod.ut 


1.3 


ctiodtester . V 


6.1 


ctiodtester.h 


1.3 


ctwe . Veqn 


1.1 


genpim.pl 


1.8 


genptab.pl 


1.12 


pimlib.pl 


Dir 


euterpe/verilog/bsrc/ctioi 


3 .2 


. checkoutrc 


1.5 


Makefile 




clean- request 


1 16 


ctioi.V 


1.10 




9.9 


ctioi . power . tab . top 


1.3 


genpim.pl 


1.1 


pimlib.pl 






Dir 


euterpe/verilog/bsrc/dp 


1.32 


Makefile 


1.40 


dp.V 
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1.29 


dptop.V , 


29.4 


dpwrap . V 


13.11 


mstepc.V 


Dir 


euterpe/verilog/bsrc/d: 


32. S 


. checkout rc 


1.33 


Makefile 


1.4 


README 


62.1 


c2e.pim 


33.6 


clean- request 


12 .1 


clocksub 


1.26 


dr.V 


1.1 


dr. clocks. ut 


1.16 


dr.conf ig.h 


43.6 


dr. power. tab. top 


1.9 


dr.ut 


1.2 


dram . regi sters 


1.1 


drba . pla 


7.11 


drbank.V 


1.7 


drbankarb . pla 


1.3 


drbankcsm . pla 


3.6 


drbanksel . Vegn 


64.2 


drbanksel . custom . pim 


67.1 


drbothbankscontrol .pirn 


1.3 


dr cd. pla 


1.2 


drclockphase . pla 


1.3 


drcolscram.pla 


67.1 


drcomraoncontrol . pim 


4.4 


drconfig2bs.pla 


70.2 


drcontrol j unk . pim 


1.3 


drcsm . states . h 


1.2 


drcstndecode . pla 


10.5 


drinstantiate.h 


1.3 


droktoact.pla 


1.2 


droktopre.pla 


1.1 


droktoread . pla 


1.3 


droktowrite .pla 


3.17 


■ drout.V 


5.5 


droutde2Sel.pla 


72.1 


droutdpcontrol .pim 


1.4 


drpads , V 


1.2 


drpagecontrolstack .pla 


1.2 


drpagecsm . pla 


1.1 


drpagev . pla 


1.3 


drpmgen.pla 


1.1 


drpop.pl a 


3.7 


drprbcsm.pla 


1.3 


drrc.pla 


1.4 


drreadcount . V 


62.1 


drreadcount .pim 


1.3 


drreadcount sel .pla 


1.3 


drresetseg.pla 


1.3 


drrowscram.pla 


1.1 


drrp . pla 


1.5 


drsamplephase .pla 


1.3 


drseqcheck.pla 


3.1 


drspacematch . Veqn 


6.2 


drtagqc .pla 


1.18 


drtester. V 


1.6 


drtester.h 


1.8 


drtop.V 


27.1 


drtop2.V 




drwritecount .pla 


1.3 


drwritedsel . pla 


20.12 


genpim . pi 


39.2 


genptab.pl 


20.16 


pimlib.pl 
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Dir 


euterpe/verilog/bsrc/dr/conf ig 


1.1 


Makefile 




dram . datasheet . explained 


1.1 


dram . datasheet . nec . 10 


l.l 


dram . datasheet . nec . 12 


1.1 


dram . system . datasheet 


1.1 


marg . c 


1.1 


system . datasheet . explained 


Dir 


euterpe/verilog/bsrc/dr/dram 


1.4 


Makefile 


1.1 


README 


1.1 


byl6_64m.ut 


1.1 


by8_16m.ut 


l.l 


by8_64m.ut 


1.1 


sdram.V 


1.2 


sdram . h 


1.1 


sdram . small . h 


1.1 


sdram . ut 


1.1 


spy . h 


1.3 


tester. V 


1.1 


tester. h 


Dir 


euterpe/verilog/bsrc/dr/ dram/mit 


1.3 


Makefile 


1.1 


mitsubishi . sdram . model 


1.1 


op.v 


1.1 


sdram . v 


Dir 


euterpe/verilog/bsrc/drio 


3.5 


. checkoutrc 


1.5 


Makefile 


5.4 


clean-request 


1.2 


drio.V 


20.5 


drio . nearpads . pirn 


9.11 


drio . power . tab . top 


1.4 


genpim.pl 


1.2 


pimlib.pl 


1.3 


power . tab . local 


Dir 


euterpe/verilog/bsrc/es 


45.3 


. checkoutrc 


1.23 


Makefile 


45.15 


clean- request 


5.46 


es.V 


5.55 


es .pirn 


65.12 


es . power . tab . top 


40.10 


es_xlu.V 


1.18 


esaddbyt.V 


60.6 


esaddbyta . V 


60.5 


esalmsum. V 


60.4 


esalmsumb.V 


1.29 


esalu64 .V 


1.10 


escla.V 


1.89 


escntrl.V 


1.29 


esomux . V 


1.4 


estop. V 


37.14 


genpim . pi 


37.1 


pimlib.pl 


13 .7 


power . tab . local 


Dir 


euterpe/verilog/bsrc/gf 


11.4 


. checkoutrc 


1.16 


Makefile 


11.8 


clean- request 


9.8 


genpim.pl 



Page 76 



1.7 gf.V 
4.15 gf.pim 

19.9 gf .power. tab. top 
1.3 gfbit.pla 

1.11 gfbyt.V 
.1-1 gftop.V 
9.1 pimlib.pl 

Dir euterpe/verilog/bsrc/gt B0M 98 0 

39.5 .checkoutrc 

8.3 2gtlb.ut 
9-4 3gtltgtlb.ut 
1.29 Makefile 
41.8 clean-request 
26.8 genpim.pl 

14 . 3 genpipedat . pi 

24 . 8 genptab . pi 

7.15 gentst.pl 

2.28 gt.V 

54.10 gt . power . tab . top 
25.21 gt_control .pirn 
7.25 gt_driver.V 

9.5 gtdone.pla 

10.12 gtinstantiate.h 

7.4 gtrdy.pla 
7.41 gtsnake.v 

7.5 gtsnakemuxctl .pla 

7 . 7 gtspmatchearly . Veqn 

7.24 gtspmatchlate.Veqn 

7 . 4 gtwe . Veqn 
26.23 pimlib.pl 

Dir euterpe/verilog/bsrc/hc BOM 124 0 

35.10 .checkoutrc 

1.30 Makefile 

40.7 clean-request 

34.6 genpim0.pl 

32.10 genpiml.pl 

12.5 gentst.pl 

1.56 hc.V 

3.15 hc.h 

8.5 hc.ut 

68.9 he 0. power. tab. top 

73 . 25 hcO_control .pirn 

68.9 hcl. power. tab. top 

73.15 hcl_control .pirn 

65.3 hc_brresp . pla 

6.2 hc_cmp6 . V 

27.17 hc_control.pim 

8.10 hc_device.v 

3.16 hc_driver.V 

4 . 2 hc_error . Veqn 
12.3 hc_fifo8.V 

12 . 3 hc_f if o8ctrl . Veqn 

3.26 hc_ostate.pla 

3 . 15 hcjpar se . Veqn 

3.13 hc_j?rbctrl.pla 

3 . 3 hc_rxcrc . Veqn 
75.2 hc_sadrsel . Veqn 
3 . 13 hc_sdecode . Veqn 
3.13 hc_sid.Veqn 

3 . 5 hc_tagmatch . V 

3 . 2 hc_txcr c . Veqn 

13.1 hcinstantiate.h 

2 7.10 pimlib.pl 

17.7 power. tab. local 
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. 


euterpe/verixog/osrc/tiz 




. checkoutrc 


15 


Makefile 




clean-reguest 


4.6 


genpim.pl 


1.15 


hz. 


9 . 8 


ftz.pim 


i°i 8 


hz . power . tab . top 






1.3 


hzmatch. V 


1.7 


hztester.V 


1 •? 


hztester . h 


4 . 2 


pimlib . pi 


4.2 


power . tab . local 


Dir 


euterpe/verilog/bsrc/ ice 


15 .4 


. checkoutrc 


\ A 


Makefile 




genpitn . pi 


1.45 


icc.V 


2.6 


icc.h 


39 . 5 


icc.pxm.txt 




ice .power . tab . top 


1C 1 1 c 


ice control. pim 


15 10 


iccinhif e . Vegn 


1.9 


iccxci6. Vegn 


1.13 


iccxci7 . Vegn 


3 . 6 


pimlib.pl 


39.2 


power . tab . local 


39.1 


txt2pim.pl 


Dir 


euterpe/verilog/bsrc/if e 


18 . 3 


. checkoutrc 


4 .2 


1 .ut 


1.13 


Makefile 




clean-reguest 


15 7 


genpim . pi 


19 




1.9 


if br . tst 


1.45 


lfe.V 


61.2 


ife.pim.txt 


40.5 


if e . power . tab . top 


15 . 14 


if e_control .pirn 


1.7 


if free . tst 


1 . i> 


if f ree5 . tst 




iinoia . est 


Q 


ifpcselil . Vegn 


2 12 


if rst . tst 


1.2 


ifwntdi3,Vegn 


1.10 


ifwntdi4 .Veqn 


28 . 1 


if wntdi6 .Vegn 


15 .4 


pimlib.pl 


15.2 


power . tab . local 


, 


■ euterpe/verilog/bsrc/ io 


• ° 


. checkoutrc 




Makefile 




clean-reguest 




genpim 0 .pi 




genpiml -Pi 




getSpiceNets 


24 ' 8 


ioO . power . tab . top 


22.10 


ioo control. pim 


24.8 


iol . power . tab . top 


22.6 


iol control. pim 


31.2 


io_buf_8 .V 


6.4 


io_if ifo.V 



BOM 49.0 



BOM 68.0 



BOM 48.0 
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6.1 io_ophase. Veqn 

6.2 io_scioff_6.V 
6-1 io_scioff_9.V 
3.1 iocount.pla 

3 . 2 iodrive . V 

3.1 iofs.Veqn 

3.12 iorate.V 

46.2 netcap_getSpiceNets.txt 

4.9 pimlib.pl 

7.4 power. tab. local 

Dir euterpe/verilog/bsrc/ig 

22.4 . checkoutrc 

12.2 l.ut 

1.38 Makefile 

24.8 clean-request 

20.9 genpim.pl 
3 iq.V 
2 iq.pim 
5 iq. power .tab. top 

20.17 iq_control.pim 

2.7 iqbr.tst 

1.10 iqfree.tst 
1 . 8 iqf ree5 . tst 

1.10 iqhold.tst 

1.11 iqh.old5.tst 

1 . 1 iqholdq2 . Veqn 

1 . 5 iqholdqq . Veqn 

3.1 iqpredq4 . Veqn 

9.4 iqrst.tst 

20.5 pimlib.pl 

20.2 power . tab . local 



Dir 


euterpe/verilog/bsrc/lt 


56.3 


. checkoutrc 


3.30 


Makefile 


56.6 


clean- request 


56.6 


genpim . pi 


56.2 


genptab . pi 


3.72 


lt.V 


68.12 


It . power . tab . top 


56.19 


lt_control.pim 


90.1 


ltmiss .Veqn 


7.8 


ltstldenbl.Veqn 


56.14 


pimlib.pl 


Dir 


euterpe/verilog/bsrc/mc 


17.4 


. checkoutrc 


1.21 


Makefile 


17.19 


clean- request 


13.17 


genpim.pl 


1.22 


mc.V 


38.6 


mc . control . obs 


48.8 


mc. control. pirn 


48.9 


mc.dataHigh.pim 


48.7 


mc . dataLow . pirn 


6.24 


mc .pim 


37.11 


mc . power . tab . top 


14.31 


mc xluc.V 


28.4 


mc_xlud.V 


1.6 


mcacc8 .V 


1.5 


mcaddbyt.V 


1.1 


mcadf32.V 


1.11 


mcalu64 . V 


1.2 


mccla.V 
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13 .2 


pimlib.pl 


16.4 


power . tab . local 


Dir 


euterpe/verilog/bsrc/mg 


14 . 3 


lstr .ut 


1 . 32 


Makefile 


1.1 


dee. in 


1.1 




1.3 


mg.h 


8 .28 


mgrst.tst 


1.23 


rslt.tst 


10.10 


str.tst 


Dir 


euterpe/verilog/bsrc/mst 


13 .3 


. checkoutrc 


1.16 


Makefile 


13.10 


clean- request 


11.6 


genpim.pl 


20.1 


msaccl6 .V 


1.1 


msadf32.v 


1.6 


msbooth. V 


20.2 


mscsaddl6a. V 


20.2 


mscsaddl6b. V 


20.2 


mscsaddl6e. V 


1.3 


mshotc. V 


20.1 


mshotca.v 


20.2 


msinl6a . V 


20.1 


msinl6b. V 


20.2 


msrcdlS.V 


20.1 


msrcdl6a.V 


20.1 


msrcdl6b.V 


1.11 


mst.V 


2.18 


mst.pim 


23.9 


mst .power . tab . top 


1.1 


mstop. V 


11.1 


pimlib.pl 


Dir 


euterpe/verilog/bsrc/nb 


46.7 


. checkoutrc 


1.45 


Makefile 


1.4 


README 


46.7 


clean-request 


31.19 


genpim.pl 


52 .6 


genptab.pl 


1.4 


muxffl7_l.V 


1.4 


rauxff 17_4 .V 


1.2 


muxffl7_5.V 


1.79 


nb.V 


31.10 


nb.h 


82 .12 


nb . power . tab . top 


31.4 


nb . toplevel . ut 


14 .11 


nb.ut 


88.16 


nbjmid.pim 


88 .15 


nb_top.pim 


9.19 


nbal6x64 . tpl 


31.22 


nbctrl. Veqn 


9.19 


nbd32x64 .tpl 


1.13 


nbfq.V 


44 .4 


nbfqcount .pla 


1.3 


nbf qprienc . pla 


1.5 


nbfqslice.pla 


44.3 


nbf ul lip. pla 






90.2 


nbgotoneslice . Veqn 


12.2 


nbholdof f .pla 


68.1 


nbholdoff3 .pla 


1.13 


nbperiph.V 



BOM 130.0 
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-3 nbpq.V 
i nbpqhelper . pla 

t nbpqptrbit 0 . Veqn 

i ribpgptrslice. Veqn 

i nbprbarb . Veqn 

1 nbprbcount.pla 
1.5 nbrq.V 

1.3 nbrqptrbitO.Veqn 
nbrqptrslice . Veqn 

2 nbtester.V 
nbtester.h 
nbvd.pla 

15 . 7 nbwe . Veqn 
120.1 nbwed.Veqn 
31.15 pitnlib.pl 

Dir euterpe/verilog/bsrc/nb/rf 
1 • 4 Makefile 
1.1 rf.ut 

1.4 rflrlw.V 

1.1 rflrlwl6wx64b.h 
rflrlw32wx64b.h 
rf tester. V 
rftester.h 

Dir euterpe/verilog/bsrc/periph 
1.6 Makefile 



p.ut 

sptest.ut 

euterpe/verilog/bsrc/rf 
l.tst 
Makefile 
dor f spy 

1.2 drvchk.V 
1.6 rf_l.V 
1.5 rf_5.V 

1.3 rf_dec.Veqn 
1.2 run.V 

spy.V 

Dir euterpe/verilog/bsrc/rg 

60.3 .checkoutrc 
lbr.ut 
le.ut 
Imul.ut 
Makefile 

2 clean- request 
4 genpim.pl 

82.4 genptab.pl 
19.23 ~ pimlib.pl 
29.17 rg.V 
82.31 rg.pim 

79.12 rg. power. tab. top 
67.4 rg_control .pirn 

1.12 rgcr.V 
rgdp . V 
rgimm.V 
rgpc . V 
52.2 rgplrO.pla 
9.28 rgrst.tst 
1.15 rslt.tst 

euterpe/verilog/bsrc/rgxmit 
. checkoutrc 
Makefile 
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8.5 


clean- request 


1.3 


genpim.pl 


1.1 


pitnlib.pl 


1.1 


power . tab . local 


1.3 


rgpcbrr7 . Veqn 


1.3 


rgwewk.Veqn 


1.24 


rgxmit.V 


19.6 


rgxmit. power. tab. top . 


1.16 


rgxmit_control . pim 


Dir 


euterpe/verilog/bsrc/ sr 


24.7 


. checkoutrc 


1.21 


Makefile 


26.11 


clean-request 


16.14 


genpim . pi 


27.7 


genptab.pl 


16.12 


pimlib.pl 


2.32 


sr.V 


3.5 


sr.h 


51.12 


sr. pim 


39.10 


sr . power . tab . top 


1.2 


sr_cla.Veqn 


16.21 


sr_control . pim 


1.9 


sr_driver .V 


3.3 


sr_eventl 6 . Veqn 


3.4 


sr_eventreg . V 


16.5 


sr_eventreg .pim 


3.6 


sr_evmaskl6 .V 


41.2 


sr_hcevent . V 


1.3 


sr_inc4 .pla 


1.3 


sr_inc4a.pla 


2.4 


sr_match . V 






3.3 


sr_radecode . pla 


1.3 


sr_timer. V 


16.2 


sr_timer.pim 


3.3 


sr_wadecode . pla 


Dir 


euterpe/verilog/bsrc/tst 


13.2 


le.ut 


13.3 


libr.ut 


13.2 


liss.ut 


13.3 


11. ut 


13.2 


lpc . ut 


13.1 


Iq.ut 


13.1 


lstr.ut 


1.24 


Makefile 


1.10 


br.tst 


1.84 


drvchk.V 


70.3 


ic.tst 


6.40 


job. tst 


1.11 


rslt . tst 


1.29 


rst.tst 


1.17 


spy .V 






6.35 


tstrst.tst 


3.2 


vervars 


3.4 


vew 


3.1 


vlwire 


Dir 


euterpe/verilog/bsrc/uu 


79.4 


. checkoutrc 






25.1 


le.ut 


25.2 


limm.ut 


25.2 


limmpc .ut 


25.1 


liss .ut 
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25 .1 




25.1 


lpc ut 


1 . 79 


Makefile 


2 .14 




78 . 9 


clean- request 


174 .1 


cnp 2res.pl 


131. 9 


evblm , pr io 


174.2 


aenni 61 "*?^ 






68 " 14 




81 2 


power . tar) . local 




sswap. tst 


169 4 


sswap8 . tst 


180.1 


uu- local -p4 . obs 


l^OO 


uu- local . obs 




uu.V 


1 37 




119 13 


uu" b 

uu . power . ab . top 


68 60 


n ro .pxm 


174 3 


uu — 1V f j , 


1 23 


uuoruv, tdcd 


1 . 13 


uubruw.Veqn 


14° 


uubypltncyuv . tdcd 




uuchkdstr 3 . Veqn 


1 ' 10 


uuchJcdstuw . Vecjn 


112 1 


uucmp2rn.V 


i ii 


uu s se u .tdcd 


1 ' 9 


u ?j 


1 15 


uunold. tst 


1.19 


uuliolduu . Veqn 


1.20 


uuimmpc . tst 


1.32 


uuimmpcut . tdcd 


24.12 


uuimmus . tdcd 


1.14 


uuisdstuv . tdcd 



1 . 1 uuisdstuvsplit 

1.24 uuissrcur . tdcd 

28.10 uu j oblstux . Vegn 

63 . 15 uumemuv . tdcd 

8.15 uumic.tst 

8 . 12 uumicut . tdcd 

9 . 8 uumicuu . tdcd 

112 . 3 uuovrlyregreg . V 

156.2 uuovrlysrcdstcyl . pim 

36.17 uuprblmfrz. Veqn 

108.6 uuprblmrO . Veqn 

108.6 uuprblmrl 0 . Veqn 

50.10 uuprblmrll.Veqn 
50.8 uuprblmrl2 . Veqn 

60.11 uuprblmrl3 .Veqn 
50.11 uuprblmr5 . Veqn 
50,1 uuprblmr6 . Veqn 
107.12 uuprblmr7.Veqn 

50.14 uuprblmr 8 . Veqn 

61.15 uuprblmr 9 . Veqn 
32.15 uuprblraup . Veqn 
50.19 uuprblmwm . Veqn 
14.35 uupreemuq.Veqn 

1.2 uupsi.pla 

8 . 3 uurbuu . Veqn 

15 . 11 uursltbypcuu . Veqn 

1.20 uursltbypuu.Veqn 

28.10 uursrvd.tdcd 

170.4 uursrvduu . tdcd 

170.2 uursrvduv.pla 

170.1 uursrvdwd.pl 

15.3 0 uurst.tst 

| 53. 2 uurstuq.pla 
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76.5 uuruptrl2 . Veqn 

84.7 uusteput . pla 

84.16 uustepuu.pla 

1.16 uuthruus . tdcd 

1.14 uuthruut . Veqn 

1.2 uuwewj .Veqn 

Dir euterpe/verilog/bsrc/xlu BOM 65.0 

28.3 . checkoutrc 
1.48 Makefile 

8 . 1 TODO 
25.1 cl.srf 
25.1 C2.srf 
26.1 c3.srf 

36.1 clean- request 

25.1 cs2.srf 

25.1 cs3.srf 

23.2 db_7a.srf 
21.5 dc_8a.srf 
8.21 genpim.pl 

22.4 misc2.srf 

22.3 misc3.srf 
8.20 pimlib.pl 

35 . 1 power . tab . local 

21 . 4 g_9a_7 . srf 
19.14 route.pl 
33.9 xl23.pim 

40.2 xl26.pim 

33.3 x456.pim 
25 . 1 xbus . srf 
24.9 xlu.V 

14.4 xlu.mpc 
35.1 xlu.nets 

33.1 xlu.noflip 

62.2 xlu.pim 

48.4 xlu.power.tab.top 

17.5 xlu.rcf 
33.7 xlu4 . obs 

39.1 xlu6.obs 

41.2 xlu_add4.V 
1.16 xlu_ctrldata . c 

1 . 2 xlu_la_r2 . c 

18.2 xlu_sr.c 
28.1 xlu_sr_c3.dir 

28.3 xlu_sr_r2 .dir 
28.1 xlu_sr_r3 . dir 
6 . 2 xlu_tr_sl . c 
28.1 xlu_tr_sl . dir 
6 . 2 xlu_tr_s2 . c 
28.1 xlu_tr_s2.dir 
6.2 xlu_tr_s3.c 
26.1 z3.srf 

25.1 zs3.srf 

Dir euterpe/verilog/bsrc/yy BOM 26.0 

1.15 Makefile 

1.2 dob2dascii 

2.2 dotestassign 

1.24 tas.pl 

2.1 test.V 

l.l yy.h 

1 . 5 yyunasm . V 

1.5 yyunasmmnesel . tdcd 

1 . 5 yyunasmmusel . tdcd 

Dir euterpe/verilog/lvs BOM 3.0 

1.8 Makefile 
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1 • 2 l_eut erpe_wrap . parm 

Dir euterpe/verilog/lvs/enetlib BOM 2.0 

1-1 . checkout rc 

1.1 Makefile 

-==> running euterpe/ . checkoutrc (Fri Aug 11 23:10:42 PDT 1995) <=== 
gmake -C ged default 

gmake [1]: Entering directory "/N/auspexS/slO/chip/euterpe/ged 1 
for LIB in • 1 toplevel rf ; do \ 

if [ -z "$LIB" J ; then continue; fi; \ 

if [ ! -f $LIB/$LIB.lib ] ; then \ 
mkdir -p $LIB; \ 

echo ' FILE_TYPE = SPICE_DIR; • > $LIB/$LIB. lib; \ 
echo 'END.' » $LIB/$LIB.lib; \ 

fi; \ 

/n/auspex/slO/chip/euterpe/tools/bin/mkgedlib -cluS $LIB; \ 

done 

rm -f tmpfile 

gmake [1]: Leaving directory "/N/auspexS/slO/chip/euterpe/ged' 
gmake -C compass /lay outs default 

gmake [1]: Entering directory "/N/auspex6/sl0/chip/euterpe/compass/layouts • 
gmake [1] : Nothing to be done for ""default » . 

gmake [1] : Leaving directory "/N/auspex6/sl0/chip/euterpe/compass/layouts ' 
gmake -C dcell dcells 

gmake [1]: Entering directory -/N/auspex6/sl0/chip/euterpe/dcell • 
gmake list dcell. topt subcells 

gmake [2]: Entering directory *"/N/auspex6/slO/chip/euterpe/dcell ' 

gmake [2]: "list' is up to date. 

gmake [2]: "dcell. topt' is up to date. 

gmake [2]: Nothing to be done for "subcells'. 

gmake [2]: Leaving directory "/N/auspex6/sl0/chip/euterpe/dcell ' 
gmake [1]: Leaving directory "/N/auspex6/sl0/chip/euterpe/dcell ' 
| gmake -C baseplate all 

gmake [1] : Entering directory "/N/auspex6/sl0/chip/euterpe/baseplate ' 
I C --d /n/auspex/slO/chip/euterpe/compass/baseplate ] j | mkdir -p 
/n/auspex/slO/chip/euterpe/compass/baseplate 

|gmake subcells /n/auspex/slO/chip/euterpe/compass/baseplate/padtext . ly 
/n/auspex/slO/chip/euterpe/compass/baseplate/baseplate . ly\ 
labels 

gmake [2]: Entering directory "/N/auspex6/sl0/chip/euterpe/baseplate ' 
gmake [2]: Nothing to be done for "■subcells 1 . 

gmake [2J: "/n/auspex/slO/chip/euterpe/compass/baseplate/padtext.ly' is up to date, 
gmake [2]: Vn/auspex/slO/chip/euterpe/compass/baseplate/baseplate. ly' is up to date, 
gmake [2]: Nothing to be done for "labels'. 

gmake [2]: Leaving directory "/N/auspex6/sl0/chip/euterpe/baseplate ' 
grep -w mobieclium_site 
/n/auspex/slO/chip/euterpe/compass/baseplate/baseplate_ecl_logic . ly \ 
I grep » A R» \ 

I awk ' {sum=sum+$9*$lo}END{print sum, " eclatoms" } ' 
4801S4 eclatoms 

grep -w mosatom_site /n/auspex/slO/chip/euterpe/compass/baseplate/baseplate_mos_logic . ly 
| grep " A R" \ 

| awk ' {sum=sum+$9*$10}END{print sum, "mosatoms"}' 
77980 mosatoms 

[ -d /n/auspex/slO/chip/euterpe/compass/baseplate ] || mkdir -p 
/n/ auspex/slO/chip/euterpe/compass/baseplate 
gmake /n/auspex/slO/chip/euterpe/compass/baseplate/stpadtext .ly 
gmake [2J: Entering directory "/N/auspex6/sl0/chip/euterpe/baseplate ' 
gmake[2]: "/n/auspex/slO/chip/euterpe/compass/baseplate/stpadtext . ly • is up to date, 
gmake [2]: Leaving directory "/N/auspex6/sl0/chip/euterpe/baseplate ' 
gmake /n/ auspex/sio/chip/euterpe/compass/baseplate/spacetrans . ly 
gmake [2]: Entering directory " /N/auspex6/sl0/chip/euterpe/baseplate ' 

gmake[2]: "/n/auspex/slO/chip/euterpe/compass/baseplate/spacetrans . ly ' is up to date. 

gmake [2]-: Leaving directory "/N/auspexS/slo/chip/euterpe/baseplate' 
jgmake /n/auspex/slO/chip/euterpe/compass/baseplate/euterpep. ly 
| gmake [2]: Entering directory "/N/auspex6/sl0/chip/euterpe/baseplate ' 
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|gmake[2]: Vn/auspex/slO/chip/euterpe/compass/baseplate/euterpep. ly is up to date. 
| gmake [2]: Leaving directory " /N/auspex6/sl0/chip/euterpe /baseplate ' 
I [ -d /n/auspex/slO/chip/euterpe/compass/baseplate ] j | mkdir -p 
/n/auspex/slO/chip/euterpe/compass/baseplate 

| gmake mms . die .pad /n/auspex/slO/chip/euterpe/compass/baseplate/baseplate_padnd_andlbl . ly 
gmake [23: Entering directory "/N/auspex6/sl0/chip/euterpe/baseplate ' 

I /n/auspex/sio/chip/euterpe/tools/bin/mk.padlist.to.mms euterpe -dbu "grep 'units [ 

3*u[ ]*=' floorplan.sgen.m4 |gawk '{print $NF+0}'~ \ 
| < /n/auspex/slO/chip/euterpe/compass/baseplate/baseplate_jpadnd.ly > mms. die. pad. tmp 
jmv mms. die. pad. tmp mms. die. pad 

| gmake [2] : "/n/auspex/slO/chip/euterpe/compass/baseplate/baseplate_padnd_andlbl . ly • is up 
to date. 

| gmake [2] : Leaving directory VN/auspex6/slO/chip/euterpe/baseplate' 

I [ -d /n/auspex/slO/chip/euterpe/compass/baseplate ] | | mkdir -p 

/n/auspex/slO/chip/euterpe/compass/baseplate 
gmake /n/auspex/slO/chip/euterpe/compass/baseplate/euterpetop. ly 
gmake [2]: Entering directory ""/N/auspex6/sl0/chip/euterpe/baseplate' 

gmake [2]: Vn/auspex/slO/chip/euterpe/compass/baseplate/euterpetop. ly' is up to date, 
gmake [2]-. Leaving directory VN/auspex6/slO/chip/euterpe/baseplate ' 
gmake [13: Leaving directory VN/auspex6/slO/chip/euterpe/baseplate' 
gmake -C gards all 

gmake [13: Entering directory *7N/auspex6/slO/chip/euterpe/gards • 
rm -rf Depend- cdl Depend-pdl 
gmake gards 

gmake [2]: Entering directory "/N/auspex6/sl0/chip/euterpe/gards ' 

/n/auspex/slO/chip/euterpe/proteus/gards /Makefile. base: 123 : Depend-pdl: No such file or 
directory 

j/n/auspex/slO/chip/euterpe/proteus/gards/Makefile.chipbase:156: Depend-cdl: No such file 
or directory 

| echo ' ./sofa/sofa_model.cdl.abgen . /sofa/sofa. pdl : \' > Depend-cdl 
|/n/auspex/slO/chip/euterpe/tools/bin/vlsimm -M -p ./sofa -v 
/n/auspex/slO/chip/euterpe/compass/vlsi. boo-dcell sofa_model » Depend-cdl 
| ERROR -- can't find cell -padcrack_uplay 1 (boo file 
*<./sofa>: :/n/auspex/slO/chip/euterpe/compass/vlsi.boo-dcell' ) 

| ERROR -- can't find cell "padsealuplay 1 (boo file ( 

. /sof a> : : /n/auspex/slO/chip/euterpe/compass/vlsi .boo-dcell ' ) 
[ERROR -- can't find cell "padm* (boo file 

/sof a>: : /n/auspex/slO/chip/euterpe/compass/vlsi .boo-dcell ' ) 
echo 11 >> Depend-cdl 

### making dependencies -- Fri Aug 11 23:12:42 PDT 1995 
# 

# leafmold cells 
# 

echo ' LEAF_CELLS = \' > Depend-pdl 

sed 's/.*/ & \\/ ; $s/\\//' /dev/null » Depend-pdl 

echo 11 >> Depend-pdl 

for cell in "cat /dev/null " ,- do \ 

echo "/$cell.pdl: \\" >> Depend-pdl; \ 

/n/auspex/sl0/chip/euterpe/tools/bin/sun4/vlsimm -M -v 
/n/auspex/slO/chip/euterpe/compass/vlsi. boo-dcell $cell >> Depend-pdl; \ 
echo ' ' >> Depend-pdl; \ 

done 
# 

# sofa-based custom cells 

echo 'SOFA_CELLS = \' » Depend-pdl 

sed 's/.*/ & \\/ ; $s/\\//' /dev/null » Depend-pdl 

echo ' ' >> Depend-pdl 

for cell in "cat /dev/null " ; do \ 

echo " . /sofa/$cell.pdl: \\" >> Depend-pdl; \ 

/n/auspex/slO/chip/euterpe/tools/bin/vlsiram -JM -v 
/n/auspex/slO/chip/euterpe/compass/vlsi. boo-dcell $cell >> Depend-pdl; \ 

echo ' • » Depend-pdl; \ 

done 
# 

# full custom cells 
# 
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echo ' CUSTOM_CELLS = \' » Depend-pdl 

sed 's/.*/ & \\/ ; $s/\\//' /dev/null » Depend-pdl 

echo ' ' >> Depend-pdl 

for cell in "cat /dev/null - ; do \ 

echo »/$cell.pdl: \\» » Depend-pdl; \ 
/n/auspex/slO/chip/euterpe/tools/bin/vlsimm -M -v 
/n/auspex/slO/chip/euterpe/compass/vlsi.boo-dcell $cell » Depend-pdl- \ 
echo ' • » Depend-pdl ; \ 

« 

# dummy cells 
# 

echo ' DCELL_CELLS = \' » Depend-pdl 
jsed >s/.*/ & \\/ ; $s/\\//. /dev/null /n/auspex/slO/chip/euterpe/dcell/list » Depend- 
jecho 11 » Depend-pdl 

for cell in /"cat /dev/null /n/auspex/slO/chip/euterpe/dcell/list\- do \ 
Depend-pdl; "\ dl: /n/auSpex/sl0 / chi P/ euter P e / c ompass/dcell/$cell . ly« » 
done 

### finished making dependencies -- Fri Aug 11 23:12:45 PDT 1995 
gmake[2] : Leaving directory VN/auspex6/sl0/chip/euterpe/gards • 
gmake[2): Entering directory VN/auspexe/slO/chip/euterpe/gards ' 
gmake[2]: *** No rule to make target \_MISSING LAYOUT FILE needed by 
sofa/sofa_model.cdl.abgen' . Stop. ~ _ Y 

gmakep]: Leaving directory VN/auspex6/slO/chip/euterpe/gards ' 
gmake[l] : *** [all ] Error 2 

gmakef.l]: Leaving directory VN/auspexS/slO/chip/euterpe/gards ' 
gmake: *** [euterpe] Error 2 

[finished at Fri Aug 11 23:19:21 PDT 1995 -- exit status 2] 
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Subject: 



Sent: 
To: 
Cc: 



From: 



vanthof (vant) 

Friday, August 11, 1995 12:50 PWI 
hardheads 

vanthof (Dave Van't Hot) 
lower layeredits in euterpe 



Just a little reminder to people working on euterpe layout edits : 

DO NOT CHANGE POLY or below. 
We have now seen occurances where POLY was edited. This is not good. 

We have also seen occurances where instances of poly waffle cells were flattened. Since 
we are not changing poly, This is also forbidden. 

To sura it up: 

- Do NOT change poly 

- Do NOT flatten or change instances which contain poly. 

We have started the tapeout process for the lower layers, therefore any cell with a lower 
layer edit will be reverted and all other edits lost as well. 



Dave Van't Hof MicroUnity Systems Eng., inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context." The Tick to Thrackazog 



Dave 
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From: vanthof (vant) 

Sent: Friday, August 11, 1995 2:34 AM 

T °: tbr (Tim B. Robinson); lisar (Lisa Robinson); geert (Geert Rosseel); hopper (Mark HofmannV 

jack (Jack Wenstrand) 

vanthof (Dave Van't Hof); manser (Steve Manser); mouss (John Moussouris); ai (Albert 
Matthews); paulp (Paul Poenisch); anh (Anh Ngo) 
Subject: euterpe lower layer fracture started at 1 1 :56 pm 8/1 0/95 



The lower drc's for euterpe finished tonight and there were 4 poly spacing errors (1 erroi 
in 1 cell repeated 4 times). I fixed this edit, got the update into the snapshot, then we 
started the fracture job for the lower layers. 

This is a new fracture flow, some new tools, and a new chip, so we may end up having to 
restart once or twice. Based on previous tapeouts with the old flow, these layers should 
be done by monday morning. 

I've also started up another fullchip lower drc. The last one took 3.5 days, so this run 
should finish by monday noon, just in time to let us know if the tapes will be good. I 
don't expect any problems though. 

One major caveat. We have not had a clean lvs run in some time. There is still some 
chance that there is a short or bad connection which would force a modification of the 
lower layers. The lvs should finish on Sunday sometime. 

Thanks , 
Dave 



pave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb. just 
not in this context . " The Tick to Thrackazog 
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From: vanthof (vant) I 

Sent: Friday, August 11, 1995 2:12 AM 

To: Tim B. Robinson 

Cc: vanthof (Dave Van't Hof) 

Subject: Re: Back on the air 



Tim B. Robinson writes: 

> I have a fullchip lower drc run going and was about to figure out how to 

> restart the fracture stuff Kurt started. He left instructions, so it should 

> be pretty simple. 

>Sounds good. Where are you getting the .ly file from for this 
>fracture? Kurt said we should be using the full euterpe.ly, but 
>obviously even though I can regenerate a new baseplate it will be some 
>time before we have a complete route again to regenerate that file. 

I'm using the snapshot euterpe layouts (and snapshot proteus layouts). 

I was just looking at how the layer id and copyright fit into the die and I'm not sure 
it's quite right yet. There is base poly from the layer id and copyright overlapping 
n+poly from the die. Base poly is the same as p+poly so in effect we have n+poly and 
p+poly overlapping. We really only create on poly mask, and it's the implants that 
determine the type. I'm not sure what will happen in this areas. This may have been the 
intended effect, I don't know and will have to ask Dan. 

We may have to restart the fracture in the morning, but that would put us on schedule. 
The fact that I started it tonight means we are effectively ahead of schedule by about 12 
or 24 hours. 



> I'll send out some status pretty soon. 

>Good. We should let people know we are right on track to get the tapes 
>out by 8/14 . 

>Tim ! 



Okey dokey. 
Dave 



Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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From: 



tor 

Friday, August 11, 1995 1:59 AM 
vanthof (vant) 
vanthof (Dave Van't Hof) 
Re: Back on the air 



Sent: 

To: 

Cc: 



Subject: 



vant wrote (on Thu Aug 10) .- 



Tim B. Robinson writes: 

>We have power again. Let me know if you need anything. 
>I'll restart the make. 

>Tim 



Great! I think I have everything under control Thanks! The getbom finished 
and only updated the one layout file like I wanted. 

OK. I'll start the build again. 

I have a fullchip lower drc run going and was about to figure out how to 
restart the fracture stuff Kurt started. He left instructions, so it should 
be pretty simple. 

Sounds good. Where are you getting the .ly file from for this fracture? Kurt said we 
should be using the full euterpe.ly, but obviously even though I can regenerate a new 
baseplate it will be some time before we have a complete route again to regenerate that 
file. 

I'll send out some status pretty soon. 
Good. We should let people know we are right on track to get the tapes out by 8/14. 



Tim 
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From: jack (Jack Wenstrand) 

Sent: Thursday, August 10, 1995 12:17 PM 

To: tbr 

Cc: euterpe 

Subject: Layout Review, 8/10/95 



Tim, 

Thank you for the suggestion, will do! I've posted recent review minutes directly to 
the Euterpe news group for the record, and with this message, I forward yesterday's 
minutes to Euterpe list. 

Regards , 

Jack 

> Date: Wed, 9 Aug 1995 21:44:27 -0700 

> From: tbr (Tim B. Robinson) 

> References: <199508100125 .SAA15922@orion.microunity.com> 



> Given the large distribution already for this mail, I think it would 

> be good to copy 1 euterpe ' . Not only would this show the rapid 

> progress being made to a wider audience, it would also become part of 

> the permanent record because mail to euterpe gets archived in a news 

> group. 

> Tim 



Subject: Layout Review of 8/9/95 



1. Next meeting: Thursday, 8/10, 3pm, Multimedia room. 

2. Action items from last time, for Thursday: 
Review of scribe lines, cell f0007 

- Beware of contact pedestal crossing iso. 
The following actions should be complete for a 
review of this cell on Thursday. 

* Dan: 

* Fill in SDEC, being careful not to short e-test 
patterns. Do not fill alignment marks. 

* Remove silicide, disconnecting these structures 
to prevent shorts. 

* Invert metals. Blocks of metal are preferred to 
perforations . 

* Std. size vias centered on the metal blocks would 
work well for the via layers. 

* Paul: verify no short to die across crack-protect 

ring after SDEC fill. 

* Johnny: Verify no e-test structure shorts after 

SDEC fill. 

* Johnny: Unstack metal layers. Make them lum wide, 

like Pollux. Replace the cranklation with long 
straight bars of metal, 
-pads : 

* Johnny: Add via45 to assist probability. 0.7um 

sq. , <: 10% density. 

3. SDEC Status: (Geert) proceeding on track. 

4. Pad Review (Paul) cell padttl 

Excellent progress. No problem with areas reviewed 
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today. With Mike's and Orlando's help, Paul expects 
to be ready for the final pad review tomorrow. 

5. PLL/bias generation cell pl_eus 

- Ml edge is centered on contact pedestal. This is 
permitted by design rules, but difficult to 
manufacture . 

* Chris Michael: Has bjt285 been simulated? Please 
talk to Al about this oft repeated transistor. 

- Several Metal issues were noted, common to many 
analog blocks, as follows. These issues occur in 
many places. This problem has been added to the 
"Priority List for Major Changes" below. No work 
should be done on these issues until the earlier 
major issues on that list have been addressed. 

. Use 2. Sum or 4 . 5um lines/1. 5um spaces in M3 for power 

strapping in analog blocks. 
. Change via23 to meet the compromise design 

rules . 

. Change M2 to 1.25 line/. 75 space parallel lines 

for shielding. 
. Where M3 is used for shielding, widen the metal 

and orient the lines orthogonal to M2. 

6. ABS Plan. 

Decision: we will not tape out or do the baekend- 
processing for the ABS layers for the 
initial metal tapeout . The will 
accelerate matters considerably. If we 
later choose to go back for ABS, we will 
need to replace the M3 mask. 

7 . Next steps . 



luture Schedule: 
Thursday 

memory cell<s) review 
final pad metal review 

test structures, pmosl, nmosl, bjtl, 
(single level ring counter?) 

Friday 

wafflizer review 

scribe-line fill f0007. Changes from Tuesday, 
+ waff lized metal . 

Monday Review Baseplate DRCs 

Review additional analog blocks. 

Priority List for Major Changes (above the line in process) • 

1. SDEC 

2. Revise pad and seal ring. 



3 . Redo vial2 on atom powerbus for damascene process . 

4. Alter M2/via23/M3 per notes of 8/9. 

Wait List 

-epllsofa: Stacking of metals and via sizing will need 
some adjustment. 
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From: 



torn (Tom Laidig [tau]) 

Wednesday, August 09, 1995 9:27 PM 

Kurt Wampler 

tau; geert {Geert Rosseei); hopper (Mark Hofmann); solo (John Campbell); vanthof (Dave 
Van'tHof) 

Re: SDEC/ContPed fixes 



Sent: 

To: 

Cc: 



Subject: 



Kurt Wampler writes: 

I've checked- in and released the edits I made to the domain control 
blocks and their subcells. There are many DRC flags around the edges 
of these cells because they're not clean without the rest of the clock 
spar interface cells that form their context. I believe I have fixed 
all the real DRC flags, but some more may crop up when they are 
combined at the next higher level. Since I will be out Thursday 
morning and all day Friday (due to a death in the 
family) I thought I would check 'em all in; if there are problems 
someone else may want to fix them rather than wait for my return. I 
hope I didn't make anything worse. 

Thanks, Kurt -- I think we can take care of any remaining DRVs. I think tomorrow 
afternoon we'll need for you to focus on preparing us to do the tapeout of the lower 14 
layers of euterpe. I believe we intend to start the fracture process Friday afternoon (or 
whenever we think we're finished fixing all lower- layer DRVs that we see from the 
currently- running DRC) . Hopefully the fracture will finish on Monday. 



~1 
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=r °m: jack (Jack Wenstrand) 

Sent: Wednesday, August 09, 1995 8:25 PM 

J o: at 9eert; paulp; hopper; vanthof; torn; anh; jack; rich; ong 

Co: ™ ouss /' ton y ; ™ a " ser > w'ngafd; mudge; cadettes; fung; kumar; tomb; yao; rip; to; ted- ky lianq- 

Subject: !%^ , S55^ graham: ^ ™ ^ t0mh °= mwS * ~* 



1. Next meeting: Thursday, 8/10, 3pm, Multimedia room. 

2. Action items from last time, for Thursday: 
Review of scribe lines, cell f0007 

- Beware of contact pedestal crossing iso. 
The following actions should be complete for a 
review of this cell on Thursday. 

* Dan: 

* Fill in SDEC, being careful not to short e-test 
patterns. Do not fill alignment marks. 

* Remove silicide, disconnecting these structures 
to prevent shorts. 

* Invert metals. Blocks of metal are preferred to 
perforations. 

* Std. size vias centered on the metal blocks would 
work well for the via layers. 

* Paul: verify no short to die across crack-protect 

ring after SDEC fill. 

* Johnny: Verify no e-test structure shorts after 

SDEC fill. 

* Johnny: Unstack metal layers. Make them lum wide, 

like Pollux. Replace the cranklation with long 
straight bars of metal, 
-pads : 

* Johnny: Add via45 to assist probability 0 7um 

sq., < io% density. 

3. SDEC Status: (Geert) proceeding on track. 

4. Pad Review {Paul) cell padttl 

Excellent progress. No problem with areas reviewed 
today. With Mike's and Orlando's help, Paul expects 
to be ready for the final pad review tomorrow. 

5. PLL/bias generation cell pl_eus 

- Ml edge is centered on contact pedestal. This is 
permitted by design rules, but difficult to 
manufacture . 

* Chris Michael: Has bjt285 been simulated? Please 
talk to Al about this oft repeated transistor. 

- Several Metal issues were noted, common to many 
analog blocks, as follows. These issues occur in 
many places. This problem has been added to the 
"Priority List for Major Changes" below. No work 
should be done on these issues until the earlier 
major issues on that list have been addressed. 

. Use 2.5um or 4 . 5um lines/l.5um spaces in M3 for pov 

strapping in analog blocks. 
. Change via23 to meet the compromise desiqn 

rules. 

. Change M2 to 1.25 line/. 75 space parallel lines • 

for shielding. 
. Where M3 is used for shielding, widen the metal 

and orient the lines orthogonal to M2 . 
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6. ABS Plan. 

Decision: we will not tape out or do the backend- 
processing for the ABS layers for the 
initial metal tapeout . The will 
accelerate matters considerably. If we 
later choose to go back for ABS, we will 
need to replace the M3 mask. 

7. Next steps.. 



Future Schedule: 
Thursday 

memory cell (s) review 
final pad metal review 

test structures, pmosl, nmosl, bjtl, 
(single level ring counter?) 

Friday 

wafflizer review 

scribe-line fill f0007. Changes from Tuesday, 
+ wafflized metal 

Monday Review Baseplate DRCs 

Review additional analog blocks. 

Priority List for Major Changes (above the line in process) : 

1. SDEC 

2. Revise pad and seal ring. 



3. Redo vial2 on atom powerbus for damascene process. 

4. Alter M2/via23/M3 per notes of 8/9. 

Wait List 

-epllsofa: Stacking of metals and via sizing will need 
some adjustment. 
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Sent: 

To: 

Cc: 



Subject: 



rrom: 



hopper (Mark Hofmann) 

Wednesday, August 09, 1995 6:47 AM 

Robert E. Van Cleef 

sysadm; vant; tau 

Re: bizarre problems with hestia? 



Robert E. Van cleef writes: 

Hestia should be ok for now. The problem was a core file in / which 
placed the partition over 104%. The midnight rdist from cronus ended 
up truncating the passwd file - grabbing a chunk out of the middle - 
leaving it without Dave's account and no entry for root. 

We need to insure that the current root partition is clean and lay plans 
for reconfiguring the system with a larger partition. 

We need to enlarge Hestia 's root partition to prevent a future occurance. 

Yes, good idea. Apparently there are many Sparc 2's with the same anemic root partition 
size (7.4Meg). This should be beefed up to prevent another Hestia-like debacle. Moving to 
the 4.1.4 release at the same time might be effcient. If this were donw we would need to 
make sure that all the special dirvers- for extra out board disks and tape drives, etc. 
are supported. I worry that it may be difficult to come up with a generic kernel that fits 
all machines. We also would want our original "hostid hack" 

which we use to move a node- locked license from one Sparc 2 to another when a machine is 
sick or goes down. 

I would also recommend that we begin moving all mail reading to gaea. 
It appears that there 

are quite a few users that need to think about moving . . . 

I bpwOfrodo, craigomnemosyne , ras@narcissus, gmo@bilbo, 
mikewOeuterpe, richopegasus, tom@clio, ong®ares, 
vanthofohestia, dicksonodemeter , jerry@sisyphus, hayesOerato, 
orlando@millennium, jef f@mercury, vo@merope, ef elias@poseidon, 
daneOmarathon, khp@spirot, wampler@thoas, and many, many 
others... about 50% of the Unix users. 

I think this is also a good idea. There is some hesitancy on the part of users because of 
NFS funnies with file locking and mail flakiness in the past. At one point we did not want 
everyone to be logged into the mail machine because it was getting bogged down. But if 
people read their mail remotely there is a finite chance that mail could be lost or, at 
least, placed in an inconsistent state. This has happened in the past. Can we support a 
mail machine? Or can we install some better mail handling system? 

Also, if Hestia is critical, we should add it to the critical machines 
listing so that the admin on duty will be paged. 

I think hestia should be added to the critical machines list. As Dave points out this 
would not have helped here- the machine did not actually crash, it just had a trashed / 
partition. 

Dave is receptive to moving the Dracula license demon to Rhea (with the other demons) as 
long as he can have root access to the machine. I believe he may have Rhea access already. 

So, if we move the license demon off Hestia, enlarge Hestia' s root partition, move mail 
off Hestia and move Dave's directory from Rama to the Auspex, I think we will be in better 
shape. I would say as long as Hestia runs the Dracula demon it should be considered a 
critical machine, and therefore entered into the critical machines list. 



Bob 



- thanks , 
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hopper 
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From: hopper (Mark Hofmann) 

Sent: Tuesday, August 08, 1 995 4:58 PM 

To: Geert Rosseel 

♦ !T ikeW L Mike Wa 9eman); vanthof (Dave Vant Hof); torn (Tom Laidig) 

Subject: Re: pad cells s/ 

Geert Rosseel writes: 

> For the metals, please just take the wide metal that is there and cut it 

> up into strips per Paul's requests. 

We don't need to make any fancy hierarchy 

> or cells. 

cL k SV f ^ ree W u th that * It<S really not the way we normally 
should do things, but I am sure that Al & Paul will make more 
changes to the pads and any hierarchy or nice layout the we 
come up with may be wasted work. 

I suggest we do a fast and not so pretty layout and maybe once it's 
all approved we can go back and make it better. I think in the 
long term we want to make some major changes to the pads anyway 
The diodes, the resistors, .. it's all a bit messy . 

Geert 

L a I rS f' a SU ^ e befc that these P ads wil1 *>*■ short-lived. Let's do just what 

next tapeout " taP6 ° Ut ' ^ Wm theSe * ads nex time 'rounS for Se 

-hopper 
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Subject: 



Sent: 

To: 

Cc: 



From: 



vanthof (vant) 

Tuesday, August 08, 1995 11:31 PM 
Tim B. Robinson 

torn {Tom Laidig); doi (Derek Iverson); vanthof (Dave Van't Hof) 
Re: release anomoly 



Tim B. Robinson writes: 

>I'm trying to get a clean bom in the eterpe tree for the next big 
>build. There is something odd in euterpe compass. The top level BOm 
>in euterpe calls out version 4.3 for this, and that is the version in 
>/u/chip. However, according to cvs log, there is a BOM 5.0 which I 
>released (as chip) the last time I was trying to do this. Any idea how 
>this release could have happened without getting propagated to /u/chip? 

Could this have been a result of the /u/chip/mdunit/ . . . disk filling up today? 

Tom went through great effort to rebuild the CVS/Entries files in 3 layout directories, 

one of which was /u/chip/mdunit/euterpe/compass/layouts . 



>The next odd thing is that in the snapshot I did a getbom -m, and got 
>the warning: 



>/n/auspex/s4l/euterpe-snapshot/euterpe/compass: BOM is newer (5.0) than the version 
specified for this directory (4.3) - extraction of this directory tree suppressed. 

>However, if I now look, the BOM itself is 5.0: 

>chip@staypuf t /n/auspex/s4l/euterpe-snapshot/euterpe/compass 8 % more 
>BOM # Created by mkbom # $Id: B0M,v 5.0 1995/07/22 17:14:44 LT chip Exp 
>$ 

>File 1.9 vlsi. boo-all 

>File 1.8 vlsi .boo-dcell 

>File 1.9 vlsi .boo- tapeout 

>Dir 19.0 BOM layouts 

>even though there are a whole bunch of downrev files: 

>chip@staypuft /n/auspex/s4l/euterpe-snapshot/euterpe/compass 7 % cvs -n 

>update cvs update: Updating . 

>cvs update: Updating layouts 

>U layouts/euterpelpadtl.ly 

>U layouts/euterpelpadtr . ly 

>U layouts/f0007.1y 

>U layouts/f0007_fill_ctpg.ly 

>U layouts/f0007_fill_ml.ly 

>U Iayouts/f0007_fill_m2.1y 

>U Iayouts/f0007_fill_m3.1y 

>U Iayouts/f0007_fill_m4.1y 

>U Iayouts/f0007_fill_vl2.1y 

>U Iayouts/f0007_fill_v23 . ly 

>U Iayouts/f0007_fill_v34.1y 

>U Iayouts/f0007_fill_v45.1y 

>U layouts/lid_euterpe__l . ly 

>U layouts/vlsi.cko 

>U layouts/vlsi.log 

>I'm going to assume we want the latest version of all these. 
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Yes, Dan checked these in today for the frame. We will need them. Of course, after the 
desxgn review today, he will need to update them a bit. 

Thanks, 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender 1 I mean, I know it, I'm not dumb iust 
not in this context . " The Tick to Thrackazog 
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From: tbr 

Sent: Tuesday, August 08, 1 995 1 1 :28 PM 

To: torn 

Cc: doi; vanthof 

Subject: release anomoly 



I'm trying to get a clean bom in the eterpe tree for the next big build. There is 
something odd in euterpe compass. The top level BOm in euterpe calls out version 4.3 for 
this, and that is the version in /u/chip. However, according to cvs log, there is a BOM 
5.0 which I released (as chip) the last time I was trying to do this. Any idea how this 
release could have happened without getting propagated to /u/chip? 

The next odd thing is that in the snapshot I did a getbom -m, and got the warning: 



/n/auspex/s4l/euterpe-snapshot/euterpe/compass: BOM is newer (5.0) than the version 
specified for this directory (4.3) - extraction of this directory tree suppressed. 

However, if I now look, the BOM itself is 5.0: 

chip@staypuft /n/auspex/s41/euterpe-snapshot/euterpe/compass 8 % more BOM # Created by 
mkbom # $Id: BOM,v 5.0 1995/07/22 17:14:44 LT chip Exp $ 

File 1.9 vlsi. boo-all 

Pile 1.8 vlsi.boo-dcell 
File 1.9 vlsi.boo-tapeout 

Dir 19.0 BOM layouts 

even though there are a whole bunch of downrev files: 

chip@staypuft /n/auspex/s41/euterpe-snapshot/euterpe/compass 7 % cvs -n update cvs update: 
Updating . 

cvs update: Updating layouts 
U layout s/euterpelpadtl . ly 
U layouts/euterpelpadtr . ly 
U layouts/f0007.1y 
U layouts/f 0007_fill_ctpg.ly 
U layouts/f 0007_fill_ml . ly 
U layouts/f 0007_f ill_m2 . ly 
U layouts/f 00 07_fill_m3.1y 
U layouts/f 0007_f ill_m4 . ly 
U layouts/f 0007_f ill_vl2 .ly 
U layouts/f 0007_fill_v23 . ly 
U layouts/f 0007_fill_v34.1y 
U layouts/f 0007_f ill_v45 . ly 
U layouts/lid_euterpe_l.ly 
U layouts/vlsi.cko 
U layouts/vlsi. log 

I'm going to assume we want the latest version of all these. 

There are also a couple of BOMs in the verify tree with a similar problem. Again I can't 
explain how they come to be that way. 
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r rom: solo (John Campbell) 

Sent: Tuesday, August 08, 1 995 1 0:20 AM 

To: vant 

Cc: solo@microunity.CQm; jack@microunity.com; al (Albert Matthews); geert (Geert RosseelV 

paulp (Paul Poenisch); hopper (Mark Hofmann); torn (Tom Laidig); anh (Anh Ngo); jack (Jack 
Wenstrand); rich (Rich McCauley); ong (Warren R. Ong); mouss (John Moussouris); tony 
(Tony Stelliga); manser (Steve Manser); wingard (Drew Wingard); mudge (john mudgeV 
cadettes; fung (Fung Chen); kumar; tomb; yao (Henry Yao); rip (Rajiv Patel); to (To Do); ted 
(Ted Chen); ky (K.Y. Ramanujam); liang; hoov (Bill Hooven); trancy (Trancy Tsao); linden 
(Linden Critchlow); anderson; alves (Maria Alves); graham (Graham Y. Mostyn); dane (Dane 
Snow); yves (Jean-Yves Michel); ras (Bob Sutherland); tomho (Tom Ho); michael (Chris 
Michael); tbr (Tim B. Robinson) 

Subject: Re: Euterpe review minutes, 4/7/95 



as vant was saying '. 

. .John Campbell writes: 

. . >as Jack Wenstrand was saying 

..>.. * John Campbell. Resis cell. Connected properly? 

■ • > • • Please check it out and send mail . 



. .>This cell, resis. ly was edited on july 14, released on aug 6 and ..>causes all ttl io 
buffers to fail lvs. does someone want to take on ..>the edit of this cell, must be done 
\n context of the chip. 

. . >my understanding is that the changes were directed by fab so maybe . . >they should 
direct the fixes so we don't unsolve what they were trying ..>to fix. 

. .>paulp?? maybe. 

..the changes were to comply with what was (at that time) the current metal ..rules. I 
believe the open is simply because the pad metal edits were ..not completed because of new 
information from the fab which invalidated . .much of the work done on the pads at that 
time. However, the lower layer ..edits were required which is why the pads were released. 

..No one seems to understand how this cell works and I must have it completed . . so I can 
start up a fullchip lvs. _If_ I can get an lvs started this morning, ..it is not going to 
be completed until late Saturday, which is over a day ..after the second run of the drc's 
will be started. If the lvs comes back ..bad, and it requires lower layer edits, then 
we've just blown the tapeout ..schedule. 

..All I need is a quick fix to make it lvs correct. The metals are being ..completely 
redone, and I'm not going to wait for that to be completed before ..starting the fullchip 
lvs (to verify the lower layers) . 

. .Dave 

it can be lashed together, unlock ttle2teu ttl3vnew and ttle2ttl. 
let's do it. but..', lets fix it for real right away. like later today. 

regards, EMail solo@microunity.com 

solo a.k.a. John Campbell phone 408 734-8100 fax 408 734-8136 
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From: 



vanthof (vant) 

Tuesday, August 08, 1 995 1 0:1 0 AM 
John Campbell 

jack@microunity.com; al (Albert Matthews); geert (Geert Rosseel); paulp (Paul Poenisch); 
hopper (Mark Hofmann); torn (Tom Laidig); anh (Anh Ngo); jack (Jack Wenstrand); rich (Rich 
McCauley); ong (Warren R. Ong); mouss (John Moussouris); tony (Tony Stelliga); manser 
(Steve Manser); wingard (Drew Wingard); mudge (john mudge); cadettes; fung (Fung Chen); 
kumar; tomb; yao (Henry Yao); rip (Rajiv Patel); to (To Do); ted (Ted Chen); ky (K.Y. 
Ramanujam); liang; hoov (Bill Hooven); trancy (Trancy Tsao); linden (Linden Critchlow); 
anderson; alves (Maria Alves); graham (Graham Y. Mostyn); dane (Dane Snow); yves (Jean- 
Yves Michel); ras (Bob Sutherland); tomho (Tom Ho); michael (Chris Michael); tbr (Tim B. 
Robinson) 

Re: Euterpe review minutes, 4/7/95 



Sent: 
To: 

Cc: 



Subject: 



John Campbell writes: 

>as Jack Wenstrand was saying 

>.. * John Campbell. Resis cell. Connected properly? 

> . . Please check it out and send mail . 



>This cell, resis. ly was edited on july 14, released on aug 6 and causes 
>all ttl io buffers to fail lvs. does someone want to take on the edit 
>of this cell, must be done in context of the chip. 
> 

>my understanding is that the changes were directed by fab so maybe they 
>should direct the fixes so we don't unsolve what they were trying to 
>fix. 

>paulp?? maybe. 

the changes were to comply with what was (at that time) the current metal rules. I 
believe the open is simply because the pad metal edits were not completed because of new 
information from the fab which invalidated much of the work done on the pads at that time. 
However, the lower layer edits were required which is why the pads were released. 

No one seems to understand how this cell works and I must have it completed so I can start 
up a fullchip lvs. _l£_ I can get an lvs started this morning, it is not going to be 
completed until late Saturday, which is over a day after the second run of the drc ' s will 
be started. If the lvs comes back bad, and it requires lower layer edits, then we've just 
blown the tapeout schedule. 

All I need is a quick fix to make it lvs correct. The metals are being completely redone, 
and I'm not going to wait for that to be completed before starting the fullchip lvs (to 
verify the lower layers) . 



Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender 1 I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 



Dave 
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From: efelias (Eldred Felias) 

Sent: Tuesday, August 08, 1 995 1 .00 AM 

To: stick (Bruce Bateman) 

Cc: geert {Geert Rosseel); bpw (B. P. Wong) 

Subject: ctag Ivs status 



The ctag lvs is almost clean. There are IS unmatched schematic devices and I haven't 
had a chance to check them yet. The next two weeks is very critical for getting euterpe 
ready for tape out and I will be helping on doing drc fixes. 
However, if you find where the problem is on ctag, I'll be glad to fix it. 

Thanks , 
Eldred 
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From: efelias (Eldred Felias) 

Sent: Tuesday, August 08, 1 995 1:00 AM 

To: stick (Bruce Bateman) 

Cc: geert (Geert Rosseel); bpw (B. P. Wong) 

Subject: ctag Ivs status 



The ctag lvs is almost clean. There are 16 )unraatched schematic devices and I haven't 
had a chance to check them yet. The next two weeks is very critical for getting euterpe 
ready for tape out and I will be helping on doing drc fixes. 
However, if you find where the problem is on ctag, I'll be glad to fix it. 

Thanks , 
Eldred 



Exhibit5, 
Page 106 



From: tbr (Tim B. Robinson) 

Sent: Monday, August 07, 1 995 9:50 PM 

To: zeus 

Cc: mouss 

Subject: Meeting summary 



Some notes from friday's general meeting. 

Bill had followed up. on actions from last week. Taking data from Microprocessor Report he 
concludes that cost per 8" wafer on a modern microprocessor capable process is $4k/wafer. 
Looking at 3 different yield models (seed, murphy, poisson) concludes that 14 mm pers side is 
at a knee on the cost curve. Bigger than that gets expensive. His bottomline is given a 
wafer cost and a defect density, we can expect to predict die cost to within 25%. 

Action: bill, tbr to get more recent data for wire statistics on euterpe and mnemo. 

Done, data supplied to bill. 

Bill then showed data on number of wires as a function of die size. 

Combining this with the previous data he could derive cost as a function of number of 
wires. Re also had data on memory cell areas but has not yet factored that into the cost 
calculation. 

Action: bill to get ram data into cost calculation. 

Todd showed slides from the second meeting of the marketing sub-group which has been 
considering modem, set top box and PC related platforms. He showed a chart relating human 
factors, applications, platforms and features. Lisar observed that with the relatively 
jiigh power levels of high performance implementations, important application areas may hot 
have been getting enough consideration, eg. 

headend equipment. Craig and gmo added studio equipment and network equipment to this 
list. 

Todd said the group was having a hard time identifying the strategic and financial 
objectives of Zeus. He noted that both the CDM and set top box involved large market 
risk. In the PC area he sees a migration to more integration of media functions. He sees 
two ways to a media computers: migration from the PC, or migration from the set top box, 
and says the PC maker have a huge advantage here. 

There was lots of discussion on this point, but I did not record clear conclusions in my 
notes . 

Some approaches to reducing risk were noted: 
Licensing 

Adopting a less product oriented and more market oriented approach 
Adopting a more component oriented strategy- 
Become less cable oriented and more PC oriented 

Hedge against slow market development by enabling other applications 

He presented a specific proposal: 

pentium general performance plus great DSP 
Offered as a PC add- in 
Offer higher integration 
Offer new functions 

There was no agreement on this! 

finally he noted that we do hard/complicated things without thinking through what we are 
going to do with the results. 
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Action: the group to consider head end, studio and network equipment applications also. 

Craig gave a brief summary of of a presentation he had made on his work on dynamic x86 
translation. 

Some good results looked possible but would rely on architectural features not implemented 
int he Euterpe design. I particular support for unaligned loads and stores. He noted 
that good support for fast branches was essential. 

He showed an example (a memory to memory operation adding to the contents of a register) 
which under interpretation would require 33 instructions but which with translation could 
be reduced to 3 . 

Further, on a superstring machine, those three instructions could execute in a single 
cycle. 

On performance measurements, gmo said booting UNIX to a prompt on Euterpe was 21 million 
instructions, which too 70 million major cycles to execute. Allowing for the fact that it 
is only attempting to use 1 cylinder, that one cylinder is less than 30% utilized. Of the 
50 million unused cycles the rough breakdown is: 

20M dcache miss ) assumes SDRAM access latency for ref il 

13M icache miss ) 

7M issue restrictions (mostly waiting for store slots) 

5M branch penalties (losing 4 cycles per branch) 

Note that this test does not include clearing memory which would be needed in real life 
because the simulator can fake that to shorten run-time. 

It was noted that in the STB application 20% of cycles were unaccounted for. 
Action: gmo, gregg, craig, hayes to get to the bottom of this and report back. 
On specmarks, Euterpe gets between 0.3 and 0.4 instructions/cycle in a single thread. 
Action: group, find data on other applications 

Action: Hayes, look at potential compiler enhancements to address some of these losses. 

I left the meeting at this point. If there was significant further discussion can someone 
post a follow up please? 

Tim 
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From: vanthof (vant) 

Sent: Monday, August 07, 1 995 4:38 PM 

To: hardheads 

Cc: vanthof (Dave Van't Hot) 

Subject: new option to rdrc/qdrc 



I've added a new option to the rdrc and qdrc scripts,- -sdec 

This option runs a special drc flow: sdecfiller.vc which runs the tapeout sdec filling 
routine and M;hen reports any drc violations associated with it. 
The types of drc errors that can occur: 

contped over white space 

coincident contped edges with poly at white space edge 
coincident contped edges with sdec at white space edge 
allpoly+sdec min space 
allpoly+sdec min width 
sdec min spacing 

There will be addition error flags which in reality are the surrounding sdec or contped 
error. The error messages will tell you which. These are areas 50 udrs around each err 
flag to give you context of what the synthesized sdec layer really looks like to help 
determine why the error occurred. 

Thanks , 
Dave 



pave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com l 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb just 
not in this context." The Tick to Thrackazog 
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From: paulp (Paul Poenisch) 

Sent: Monday, August 07, 1 995 1 0:46 AM 

To: vant 

Cc: geert (Geert Rosseel); torn (Tom Laidig); hopper (Mark Hofmann) 

Subject: Re: pad metals 



> Hi guys, since the lower layers seem to be done (except for what to do 

> with 20. 85. 30. a errors), I was wondering what the status of the metals is. 

> The reason is I am about to launch a fullchip lvs to verify the lower 

> layers are okay (no shorts through poly, etc, etc) . However, if the 

> metals are going to cause shorts, I can't do that and we will need the 

> metals at least shorts free to tapeout the lower layers. Any ideas? 

> Thanks, 

> Dave 



There may be some shorts in the pad cells due to the changes that were made in the diodes 
there. I'll take a look at it this morning with Orlando, we should be able to elliminate 
the shorts simply by removing all the contact pedestal, but I'm not sure what that would 
do to the LVS. 

Paul. 
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From: paulp (Paul Poenisch) 

Sent: Monday, August 07, 1 995 1 0:43 AM 

To: vant 

Cc: geert (Geert Rosseel); orlando (Orlando Hernando); torn (Tom Laidig) 

Subject: Re: pads 



> Orlando Hernando writes: 

> >Howdee , 

> >I just finished drc'ing all of the pad cells. There are some error 

> >flags that 

> >reraain: 

> > floating waffle poly's should go away at the full {including metals) drc. 

> > flags at the cell edges should go away at the next level. 

> > error flags in the seal and crack areas that i'm not sure if ok: , 



> > error flags in the pwrbase r20.85.30a min Nact space to polylsi 

> > when not on 

•? > base or hurried contact=0 

> >Dave, if ya'll can stop by my area monday morning i'd like to have you check them out. 



> >anything checked out. The drc error files (-lower) are also there if 

> >you want to see them. 



> Thanks Orlando. I may check these in this weekend to get everything 

> ready for tapeout. 

> I am concerned about the drc error in pwrbase, 20. 85. 30. a This is a 

> real error according to the design rules I have. This rule is to 

> prevent us from putting silicide on top of gates. We will have 

> hundreds of thousands of these errors in euterpe unless this is either fixed < 
change the rule. 

> Paul, can you comment on this? The lower layers were to be frozen at 

> midnight on friday. So either we delay the freezing on this until 

> it's resolved or we let it go. 

> I'm for letting it go {changing the drc flow) unless it will cause a 

> nasty short. Mainly because we need to get this silly chip frozen... 

> Thanks. 
Dave 
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Sorry I didn't respond to this earlier, I don't have access to e-mail at home. 

I agree with you Dave, we should let this go. I didn't have Orlando do any- thing to poly 

1 silicide because it's now considered one to the "metal" layers. 

As a result when we took the buried contacts out of the crack and seal rings and the f 
pwoerbase cell we ended up with poly 1 silicide over gate oxide. When we go back to 
finish the metal layers for these cells we will take care of these erorrs. 

Paul. 
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From: hopper (Mark Hofmann) 

Sent: Monday, Aug ust 07, 1 995 1 :28 AM 

To: vant 

CC! ^tS^SSrl^l^SSS 96 ^ ^ ^ P ° enisch): Vanthof < Dave 

Subject: Re: pad cells ° SSee 



vant writes: 
Hi guys, 

I've checked in all the pad cells. I think they are now drc clean for 
the lower layers in the context of euterpe. The next thing to check for 
lLt° ? n5Ur ? 1 . t ^ r ? * re n ° metal Sh ° rtS so 1 ^n run a fullchip Ivs. Without 
that, I can't finish the tapeout of the lower layers by the end of the week. 

You will not need to work from ray /u/vanthof /compass/mobi/euterpe/pads 
directory anymore. All you need to do is go back to your normal compass 
directory for euterpe as all pad cells are now checked into proteus. 

I have locked all cells down. If you need to work on any cells, please let 
me know and I'll unlock them. 

Thanks, 
Dave 



Thanks for all the work, Dave. 

We will channel requests for unlocking through you. 
-hopper 
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From: 
Sent: 
To: 
Cc: 



vanthof (vant) 

Monday, August 07, 1995 3:09 AM 

orlando (Orlando Hernando); mudge Gohn mudge); pautp (Paul Poenisch) 
vanthof (Dave Van't Hot); geert (Geert Rosseel); hopper (Mark Hofmann) 
pad cells 



Subject: 



Hi guys, 



I've checked in all the pad cells. I think they are now drc clean for the lower layers 
in the context of euterpe. The next thing to check for is to ensure there are no metal 
shorts so I can run a fullchip lvs. without that, I can't finish the tapeout of the lower 
layers by the end of the week. 

You will not need to work from my /u/vanthof /compass/mobi/euterpe/pads 

directory anymore. All you need to do is go back to your normal compass directory for 
euterpe as all pad cells are now checked into proteus. 

I have locked all cells down. If you need to work on any cells, please let me know and 
I'll unlock them. 



Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context." The Tick, to Thrackazog 



Thanks , 
Dave 
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From: vanthof (vant) 

Sent = Sunday, August 06, 1 995 1 0:55 PM 

To: john mudge 

P au, P (Pa"' Poenisch); orlando (Orlando Hernando); hopper (Mark Hofmann); geert (Geert 
Rossee!); torn (Tom Laidig); mudge O'ohn mudge) v 
Subject: Re: Returned mail: User unknown (twd) 



Cc; 



john mudge writes 
>Each, 



>I thought that the daily meetings were going to grind through the 
petals on the pads. If we think that that is going to' take a long time 
>then we could fake up something on the pad just to get it through the lvs 
>Are there problems out side of the pads? 

> j ohnnymudge 

Ho Jm^ ° f eut ?P e ? hat 1>m trying to lvs. I'm counting on the new pads to have 

lZ« ^ ^ T" 7 the n6W ' final lower la ^ ers of eut erpe lvs clean, running 
Sanged 9 P 13 ^ 9 ° in9 t0 tel1 me mUCh es P eciall y the lower la™ Save 

All I need is metals that are lvs clean. I don't need them drc clean for the lvs run. 

Thanks , 
Dave 

™Z!u V S'? H ° f " icroU nity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com l 408 734-8100 ' 

!^ d ? n, ^ kn ° W meanin 3 ° f the word surrender! I mean, I know it, I'm not dumb iust 
not m this context." The Tick to Thrackazog " ]usc 
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Subject: 



From: 



Sent: 

To: 

Cc: 



vanthof (vant) 

Sunday, August 06, 1995 11:38 AM 

paulp (Paul Poenisch); Orlando (Orlando Hernando); johnny 

vanthof (Dave Van't Hot); hopper (Mark Hofmann); geert (Geert Rosseel); torn (Tom Laidig) 
pad metals 



Hi guys, since the lower layers seem to be done (except for what to do with 20. 85. 30. a 
errors) , I was wondering what the status of the metals is. 

The reason is I am about to launch a fullchip lvs to verify the lower layers are okay {no 
shorts through poly, etc, etc). However, if the metals are going to cause shorts, I can't 
do that and we will need the metals at least shorts free to tapeout the lower layers. Any 
ideas? 



Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 



Thanks , 
Dave 
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From: 



vanthof (vant) 

Sunday, August 06, 1995 11:14 AM 

tbr (Tim B. Robinson); hopper (Mark Hofmann); geert (Geert Rosseel); lisar {Lisa Robinson) 
vanthof (Dave Van't Hot); torn (Tom Laidig); wampler (Kurt Wampler) 
fulichip euterpe Ivs finished. 



Sent: 

To: 

Cc: 



Subject: 



The euterpe fulichip lvs finished about 3:10 this morning. Here's the stats: 



NUMBER OF UN- MATCHED SCHEMATICS DEVICES 
NUMBER OF UN- MATCHED LAYOUT DEVICES 
NUMBER OF MATCHED SCHEMATICS DEVICES 
NUMBER OF MATCHED LAYOUT DEVICES 



479 
327 

= 2106530 
= 2106630 



I have not had time to look at it yet. Plus with the drc edits that have been made, I 
believe the next lvs run will be much cleaner (many shorts were found in the drc fixing 
process) . 

I'll try to take a look at it this morning. The results are: 
/u/vanthof /compass/mobi/euterpe/tapeout/euterpe. compare/euterpe . lvs 



Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1408734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
iiot in this context." The Tick to Thrackazog 



Thanks , 
Dave 



Exhibit 5. 
Page 117 



From: vanthof (vant) ! 

Sent: Saturday, August 05, 1 995 1 1 :49 PM 

To: Orlando Hernando 

Cc: geert (Geert Rosseel); orlando {Orlando Hernando); paulp (Paul Poenisch); vanthof (Dave 

Van't Hof); torn (Tom Laidig) 
Subject: Re: pads 



Orlando Hernando writes: 
>Howdee, 

>I just finished drc'ing all of the pad cells. There are some error 

>flags that 

> 

>remain: 

> floating waffle poly's should go away at the full (including metals) drc. 
> 

> flags at the cell edges should go away at the next level. 
> 

> error flags in the seal and crack areas that i'm not sure if ok: 

> rl5.85.35a min Pact space to polylsi when not on base or hurried 

> contact=0 

> error flags in the pwrbase r20.85.30a min Nact space to polylsi when 

> not on 

> base or burried contact=0 

>Dave, if ya'.ll can stop by my area monday morning i'd like to have you check them out. 

>I»ve been working in /u/vanthof /compass/mobi/euterpe/pads so i don't 
>have 

>anything checked out. The drc error files (-lower) are also there if 
>you want to see them. 

>See ya 

>oh 

Thanks Orlando. I may check these in this weekend to get everything ready for tapeout. 

I am concerned about the drc error in pwrbase, 20. 85. 30. a This is a real error according 
to the design rules I have. This rule is to prevent us from putting silicide on top of 
gates. We will have hundreds of thousands of these errors in euterpe unless this is 
either fixed or we change the rule. 

Paul, can you comment on this? The lower layers were to be frozen at midnight on friday. 
So either we delay the freezing on this until it's resolved or we let it go. 

I'm for letting it go (changing the. drc flow) unless it will cause a nasty short. Mainly 
because we need to get this silly chip frozen. . . 

Thanks . 
Dave 

Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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From: 



vanthof (vant) 

Saturday, August 05, 1995 1:09 PM 
Geert Rosseel 



Sent: 
To: 
Cc: 




Subject: 



Re: euterpe lower drc status 



Geert Rosseel writes: 

>Orlando is currently working on the pad lower layers. He was going to 
>finish it as fast as possible. 

>Orlando brought up a good point. He is really worried about poly to 
>poly shorts in the pads since we cannot have floating poly and it's 
>hard to figure out what poly is hooked up to what supply without having 
>the metals done ... 



he's done, I'll start up an lvs (which includes a shorts check). 

any shorts, I'll kill the lvs part and extract the shorts. The shorts part 



Geert 



Dave 




not dumb. . . just 
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From: 



hopper (Mark Hofmann) 
Saturday, August 05, 1995 6:03 AM 
Geert Rosseel 

lisar (Lisa Robinson); tbr (Tim B. Robinson); vanthof (Dave Van't Hof); torn (Tom Laidig); 
wampler (Kurt Wampler) 
Re: euterpe lower drc status 



Sent: 
To: 
Cc: 



Subject: 



Geert Rosseel writes: 

Orlando is currently working on the pad lower layers. He was going to finish 
it as fast as possible. 

Orlando brought up a good point. He is really worried about poly to poly 
shorts in the pads since we cannot have floating poly and it's hard to 
figure out what poly is hooked up to what supply without having the metals 
done ... 

Does he need all metals or only metal 1? I think the plan for metal 1 was kind of stable- 
or am I wrong? 



-hopper 
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From: geert (Geert Rosseel) 

Sent: Saturday, August 05, 1 995 1:01 PM 

To: hopper; lisar; tbr; vanthof 

Cc: tom; wampler 

Subject: Re: euterpe lower drc status 

Orlando is currently working on the pad lower layers. He was going to finish it as fast as 
possible. 

Orlando brought up a good point. He is really worried about poly to poly shorts in the 
pads since we cannot have floating poly and it's hard to figure out what poly is hooked up 
to what supply without having the metals done ... 
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From: 



William Herndon [bi!!@microunity.com] 
Saturday, August 05, 1995 12:40 PM 
Tim B. Robinson 



Sent: 
To: 
Cc: 



Bruce Bateman; Craig Hansen; Drew Wingard; Geert Rosseel; Jack Wenstrand; John 



Subject: 



Moussouris; Steve Manser; john mudge 
Re: aug3 minutes, next meeting aug10 



thx, i will add the numbers to my spread sheet., it might be useful to have the breakdown 
by layer because i am assuming all of layer 2 is available for routing, and it isn't. 

On Fri, 4 Aug 1995, Tim B. Robinson wrote: 



> William Herndon wrote (on Fri Aug 4) : 

> The "old business" action items from the aug 4 meeting were: 

> 1. more data points on wire length etc. from other data bases (i'll get 

> it from tbr) 

> The latest euterpe route has 88458 nets and a total of 4976S387 

> microns. I don't have the breakdown of the layers but I should be 

> able to get it if you need it. 

> 

> The mnemo route has 2809S nets and a total of 20741901 microns. 



> Tim 
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From: 
Sent: 
To: 
Cc: 

Subject: 



vanthof (vant) 

Saturday, August 05, 1 995 1 0:33 AM 
Mark Hofmann 

vanthof@microunity.com; tbr (Tim B. Robinson); lisar (Lisa Robinson); geert (Geert RosseeiV 
torn (Tom Laidig); warn pier (Kurt Wampler) 
Re: euterpe lower drc's finished. 



Mark Hofmann writes: 



> Thanks, Dave 

>I did a quick grep thru the file [ 

-vanthof /compass/mobi/euterpe/tapeout/euterpe_lower. err ] abd found: 

> 2:9 r56.b: Min Polyl feature space = 10 udrs; 

> 30: 9 r56.d: Max Polyl feature space = 10 udrs; 

> 48: 9 r40&45&50&55.80.a: Max Polyl overlap of SDEC = 0 udrs; 
9 r80.a: Min SDEC feature size =10 udrs; 
9 r80.b: Min SDEC feature space = 10 udrs; 

9 r80.90.a: Min Contact Pedestal overlap of SDEC is 10 udrs; 



156: 
206: 
3434: 



white space = 3udrs) 



3606: 

> 3614: 

> 3654: 

> 4690: 

> 8542: 
udrs; 

> 19530: 

> 19802: 
Aiidrs ; 

> 20630: 
>udrs ; 

> 21094: 
>wide = ; 



9 r80.90.56.a&b: Min SDEC space to all ContPed over polyl. (To contped over 
= 3udrs) is 2 udrs; 



9 r81.a: Min allpolyl+sdec feature size = 10 udrs; 
9 r81.b: Min allpolyl+sdec feature space = 10 udrs; 
9 r85.a: Min Polyl Silicide feature size = 10 udrs; 
9 r85.90.a: Min Polyl Silicide space to all Cont Ped is 5 udrs; 
9 r85.90.56.a: Min Polyl Silicide overlap of Cont Ped & Polyl feature size ; 

9 rl0.20.b: Min Nwell space to n+active = 29 udrs; 

9 rl5 20. 81. a: All poly OR d sdec must enclose all active by 3 



rl5.20.10. 



Min P+Act in Nwell to N+Act not in Nwell =40 
min active ext into polyl for devices • 



14 udrs 



9 rl5.40 

> 64682: 9 rl5.40.a: Min P+Polyl enclosure of P+Active is 3 udrs; 

> 64690: 9 r20.85.30.a: Min N+ Act space to Polyl Sil when NOT on 
>Buried Cont = 0 udrs; 

> 65318: 9 r40.45.a: Min P+Polyl space to N+Polyl is 10 udrs; 

> 65346: 9 r40&45&50 . 85 . 80 . a : Min polyl encl of plsil at non- butting 
>contact edge = 2 udrs ,- 

>This shows most (2/3) of the errors are: 

> rl5.40.c: min active ext into polyl for devices < 14 udrs wide = ; 

> udrs; 



Yes, I believe that most of the errors will be in areas that Eldred just cleaned up as I 
started the drc on monday and he's been fixing lots of things since then. In fact, the cr 
block is drc/lvs clean. I'm not sure about the ctag. 

I'll load up this file and see where the error are. 

Thanks , 
Dave 



Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
anthof@microunity.com 1 408 734-8100 

'I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb -just 
not in this context." The Tick to Thrackazog 
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Prom: hopper (Mark Hofmartn) 

Sen * Saturday, August 05, 1 995 2:57 AM 

To: vant 

Cc: f br B - Rojinson); lisar {Lisa Robinson); geert (Geert Rosseel); vanthof (Dave Van't Hot)- 

torn (Tom Laidig); wampler (Kurt Wampler) 
Subject: Re: euterpe lower drc's finished. 



vant writes: 



Sv^i e L 4 i daYS ^ C 2? Plet ? the l0W6r * rc ' B 1 need to see what chec ks are 
taking so long, but there is very little I can do about it (except run on 
the alpha machine . . . ) * 

Okay. I take it, it is the Dracula part of the flow which is limiting things? 

The output file is almost 2 MB in size. Not bad, but bigger than 
I had hoped. 

I have not looked at it yet tonight, but will do so in the morning. 



Thanks, Dave 

J abd ?ot£d? k thrU filS [ ~ Vanthof / COTn P ass / mobi / eut «^Pe/tapeout/euter P e_lower.e 

2: 9 r56.b: Min Polyl feature space = 10 udrs; 
.30: 9 r56.d: Max Polyl feature space = 10 udrs; 
48: 9 r40&45&50&55.80.a: Max Polyl overlap of SDEC = 0 udrs - 
" r80.a: Min SDEC feature size = 10 udrs; 

9 r80.b: Min SDEC feature space = 10 udrs; 

9 r80.90.a: Min Contact Pedestal overlap of SDEC is 10 udrs- 
! 3udrs) 'is'^drs 111 SDEC SPa ° e t0 ^ C ° ntPed over P 0 ^ 1 - (To contped over 
9 r81.a: Min allpolyl+sdec feature size = 10 udrs; 
9 r81.b: Min allpolyl+sdec feature space = 10 udrs; 
9 r85.a: Min Polyl Silicide feature size = 10 udrs- 
9 r85.90.a: Min Polyl Silicide space to all Cont Ped is 5 udrs; 
9 r85.90.56.a: Min Polyl Silicide overlap of Cont Ped & Polyl feature size = 



156 
206: 
3434: 
white space 
3605 
3614 
3654: 
4690 
8542 
udrs ; 
19530 
19802 
20630 
21094 
64682 
64690 
65318: 
65346: 
udrs ; • 

This shows most (2/3) of the errors are: 

rl5.40.c: min active ext into polyl for devices < 14 udrs wide = 2 udrs; 
-hopper 



9 rl0..20.b: Min Nwell space to n+active = 29 udrs; 
9 rl5 20. 81. a: All poly OR d sdec must enclose all activ 
9 rl5.20.10.a: Min P+Act in Nwell to N+Act not in Nwell 
9 rl5.40.c: min acti 
9 rl5.40.i 



by 3 udrs,- 
4 0 udrs; 

ext into polyl for devices < 14 udrs wide = 2 udrs; 
Mm P+Polyl enclosure of P+Active is 3 udrs; 
9 r20.85.30.a: Min N+ Act space to Polyl Sil when NOT on Buried Cont = 0 ud 
9 r40.45.a: Min P+Polyl space to N+Polyl is 10 udrs • 

9 r40&45&50.85.80.a: Min polyl encl of plsil at non-butting contact edge = ; 
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From: 
Sent: 
To: 
Cc: 



Tim B. Robinson [tbr@gaea.microunity.com] 
Friday, August 04, 1995 11:52 PM 
William Herndon 

Bruce Bateman; Craig Hansen; Drew Wingard; Geert Rosseei; Jack Wenstrand; John 
Moussouris; Steve Manser; jdhn mudge; zeus technology committee - William Herndon 
aug3 minutes, next meeting aug10 



Subject: 



William Herndon wrote (on Fri Aug 4) : 

The "old business" action items from the aug 4 meeting were: 

1. more data points on wire length etc. from other data bases (i'll get 

it from tbr) 

The latest euterpe route has 88458 nets and a total of 49766387 microns. I don't have the 
breakdown of the layers but I should be able to get it if you need it. 

The mnemo route has 28096 nets and a total of 20741901 microns. 



Tim 
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From: 
Sent: 
To: 
Cc: 

Subject: 



pmayer (Patricia Mayer) 
Friday, August 04, 1995 1:04 AM 
tbr 

pmayer 

Re: Bad board news 



> From tbr Thu Aug 3 18:46:47 1995 

> To: pmayer (Patricia Mayer) 

> Subject: Re: Bad board news 

> Patricia Mayer wrote (on Thu Aug 3): 

However, because of the tab, 7 mil pads spaced at 11. a, the pin to 

> treats ^ 4 ' 8 ' line t0 ^ is 5 " 3 and line to line is 5.8. The TAB 

> S S ^^i° n t0 * ^ ^ ^ Ut DRC ' S ar€ global across the boar d ^ Allegro. 
^ r a °Z T X - a 6 mi1 grid is used ' the rest is ea «y (easier said-). 

> I don't have any understanding why the grid wasn't utilized and respected. 

> But even if you use a Smil grid, do you not still have the problem 

> that you have to violate that in the region of the pads? 

No because the line to line is rule is 5.8 just for that reason Alleqro allows for 

trd?^^ f °H gr±d . Pad and t0 a 6 mil grid < Thats the beauty of Se grfd ) I had 

to draw this for myself, perhaps we could meet sometime tomorrow for I short meeting. 

> > Anyway, after I reset the rules there were 171 errors! Of course 

> > the design 

> > summary we reviewed during our meetings was based on the erroneous 

> > setting so 

> > it looked great. 

> > 

> > How big a deal is it to edit these to correct them? 

> I^d estimate at least a two weeks per board (except Herminatior) . After 

> traces and via locations are fixed, the inner layer shapes need to be 

> ^cumSnts" alS ° t0 5) al ° ng With the dri11 and supporting 

> That sounds like a lot . 

Yes, but with the way its sorted out, I think it can be two weeks total. 

> > 

> > This also effects the Euterpe XRAM which might be easier to re-do 

> > once the 

> > Euterpe module is fixed. 

> > The Mnemo module had 229 errors. This will need editing for the 

> > new pinout a 

> > anyway . 

> > Are they mostly in the DRAM area, or on the hermes channel? 

5/5 seeing about 100 of the errors are around the DRAMs where we do have 
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> routing between the surface mount pads. 

> Was the 5/5 explicitly intended in those areas or did it just creep 

> through because of the incorrect DRC? 

Intended, we have 15 mils space between these pads and just like on Hestia it makes sence 
to hook these up on the same side and the pads in order to avoid many many vias. 

> The rest is random expecially in 

> areas densly populated with 45 degree lines. These area's, of course, have a 

> lower spacing then the parallel lines. 



> > And the Herminator has 24 errors. These are just spacing for the 

> > vias to 

> > provide inner layer, gnd and vdde, coverage between the vias. 

> > Does this mean we get close to slots again? 

> Yes, and that wasn't caught at a review either. I don't think its a big 

> deal 

> on the herminator but I don't see why we shouldn't fix it. 



> , > I'm sure all of this is fix- able. 

> > 

> Great . Jay did stop by and mentioned he had a ring pinout and he would 

> start 

> working on the schematics since Ngau is out and I'm working on the Euterpe 

> bare die test board (MMS membrane on the round card). I would think thats 

> the next highest priority in line and I thought I'd make time to reroute 

> the Pandora Euterpe. 

> Yes, Cronus and Euterpe have to take priority over mnemo and the 

> bridge 



Thank you for identifying the priority. 



> I created a macro but that still requires the layout designers remember to 

> 'run' the damn thing. (I'm resisting "having an attitude" on this but I'm 

> very disappointed and on occasion can't help myself.) 

> Sometimes people resist automation because they see it at first as an 

> intrusion on their control of their own work. You have to sell it as 

> a tool which improves productivity and quality so the result of their 

> work is more highly valued. 

Yes I understand. Thank you for the attatude adjustment, I'm already regaining my sence of 
humor . 



> > I think in view of things said at the meeting today this would be just 

> > the right time to raise that. 

> _ Howard seemed to think "extra hours" would be OK. It seems as though he 

> the re-pinout as the problem.? 

> Sorry I'm out of context. You mean the change to the mnemo/dram interface? 

Right, sorry for throwing you off. I ment the repinout on mnemo was seen as a problem. 
Howard is a good guy, I need to keep up the sell and remind him and myself that he/we 
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is/are valued. I think I'll move him to Euterpe while I finish up the guidelines. 



> > Given this surprise I'm wondering how fine we should cut things in 

> > getting first versions of the boards fabed. We have fairly 

> > conservative numbers in the schedule for fab and assembly, but given 

> > the possibility of something of this seriousness not being picked up 

> > till Hadco are looking at the artwork {and I guess based on past 

> > experience there has always been some issue) , we may want to look at 

> > sending them out earlier. 

> I really think this is a GREAT idea. I'll work with Philip to prepare an 

> evaluation package for manufacturing as soon as we are done. An evaluation 

> may even be free!? 

> OK thanks. 



> I'll update the schedule and have that out by the end of the day. 

> I suppose I need to take this to the Pandora meeting. 

> Yes, but the best thing would be to try and get lisar to integrate it 

> with the big schedule. 

OK I've already mailed her on this. 



-Pattie 
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From: pmayer (Patricia Mayer) 

Sent: Friday, August 04, 1 995 12:48 AM 

To: howard; ngau 

Cc: tbr; pmayer 

Subject: PCB priorities 



In light of the new priorities set at the Comms meeting, we have new priorities! 
Tim B. Robinson wrote (on Thu Aug 3) : 

>Cronus and Euterpe have to take priority over mnemo and the bridge. 
> Well, not explicitly mentioned, but the backplane and ISA cards are 
>just as essential as Cronus and Euterpe for the system bring up. 

Howard, will you please take the Pandora -Euterpe module first? Keep up the good work on 
the Euterpe test boards tool Then on to Mnemo. 

Ngau, please continue the ISA first (since its pretty well defined), then continue the 
Backplane . Then on to the Bridge . " 

I'll continue the Euterpe Round card and Cronus. 

Of course things may need to be moved around so I appreciate your flexability. 

Thanks 
-Pattie 
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From: tbr 

J ent: Thursday, August 03, 1 995 8:47 PM 

™ : pmayer (Patricia Mayer) 

Cc: pmayer 

Subject: Re: Bad board news 



Patricia Mayer wrote (on Thu Aug 3) : 

Xo^tM/S S ^SS SViE? StU1 i ™ «-« you have to 

> How big a deal is it to edit these to correct them? 

sirs' ^&iT£rtats ssrsffi.^- tta 

That sounds like a lot. 

J SiS^£21: Sed^^ 6 ™ WMCh bS to the 

: 2ywS em ° m ° dUle 229 err ° rS - ™ S Wil1 need ^ting for the new pinout 
> Are they mostly in the DRAM area, or on the hermes channel? 

S"<,Sct / D R ?? PliCitly lntended th °" O' d « " ««P through because of t ha 

> Does this mean we get close to slots again? 

Yes, and that wasn't caught at a review either t don't- „v 

on the herminator but I don't see why we "SSdn't ?L i£ ^ " ^ deal 

> I'm sure all of this is fix-able. 
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> Can you assess the effort required so we can decide priorities? Based 

> on todays meeting it's clear we have to have Euterpe and Cronus as 

> the top priorities, though I think our current scheduling says we have 

> these in time even with the other things going on. Jay is going to 

> shift focus from the bridge to Cronus for a while. 

Great. Jay did stop by and mentioned he had a ring pinout and he would start 
working on the schematics since Ngau is out and I'm working on the Euterpe 
bare die test board (MMS membrane on the round card) . I would think thats 
the next highest priority in line and I thought I'd make time to reroute 
the Pandora Euterpe . 

Yes, Cronus and Euterpe have to take priority over mnemo and the bridge 

Howard is working on the Euterpe Yamaichi socket for testing the TAB device 
and Mnemo. I need to verify the constraints are in place for the boards 
Ngau has the ISA, Backplane and Bridge. Perhaps when she gets back, she 
can pick up on the Euterpe and definitly the Euterpe xram. 

Well, not explicitly mentioned, but the backplane and ISA cards are just as essential as 
Cronus and Euterpe for the system bring up. s 

> In the long term, I have already added a copy of the DRC Constraint form to 

> the guidelines. As a matter of fact, thats what I was testing when I discovered 
this. I've also added a requirment to print the DRC constraint settings for 

> the design reviews along with the Summary report currently brought to the ' 



> That's a good idea. How are the DRC's run and how is the ruleset 

> selected? Is there any way to automate this (eg with Makefiles) so 

> we can guarantee to ,get the standard flows from a shared place? 

The ruleset is selected based on the smallest rules and they are on-line 
updates. The designer is responsible for turning the graphics on and there 
is an 'update DRC ' command to verify the current statistics. 
For areas like the DRAM, I was planning a "before" where the DRC's are set 
to 5.8/6 and then "after" where the DRC's are set to 5/6. This will give us 
an accurate understanding of the DRAM area and DRC's waivable. This actually 
might have been why the DRC's were set to 5 spacing but combined with the 
inaccurate grid setting of 1 mil,, its fatal. 

Good automation suggestion (must be why your the boss making the big bucks) 
I created a macro but that still requires the layout designers remember to 
'run' the damn thing. (I'm resisting "having an attitude" on this but I'm 
very disappointed and on occasion can't help myself.) 

Sometimes people resist automation because they see it at first as an intrusion on their 
control of their own work. You have to sell it as a tool which improves productivity and 
quality so the result of their work is more highly valued. 



> In the short term, I need to ask Howard to put in more hours. He's been really 

> good at putting in his 4 0 {hourly minded) but I need to reitterate your offer 

> statement that this is a salery position at a startup. We expect the hours. 

> I think in view of things said at the meeting today this would be just 

> the right time to raise that. 

Howard seemed to think "extra hours" would be OK. It seems as though he sees 
the re-pinout as the problem.? 

Sorry I'm out of context. You mean the change to the mnemo/dram interface? 

> I'm really sorry about this, and I'm glad I caught it now. Also in the future 

> I will be reviewing the data on-line to ">=>rk the check list. 
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> Better now than later. Again if there is any opportunity to automate 

> to remove manual steps that could be subject to error let's look at it. 

> Do you have any further thoughts or suggestions? 

> Given this surprise I'm wondering how fine we should cut things in 

> getting first versions of the boards fabed. We have fairly 

> conservative numbers in the schedule for fab and assembly, but given 

> the possibility of something of this seriousness not being picked up 

> till Hadco are looking at the artwork {and I guess based on past 

> experience there has always been some issue) , we may want to look at 

> sending them out earlier. 

I really think this is a GREAT idea. I'll work with Philip to prepair an 
evaluation package for manufacturing as soon as we are done. An evaluation 
may even be free!? 

OK thanks. 



I'll update the schedule and have that out by the end of the day. 
I suppose I need to take this to the Pandora meeting. 

Yes, but the best thing would be to try and get lisar to integrate it with the big 
schedule. 

Tim 
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From: pmayer (Patricia Mayer) 

Sent: Thursday, August 03, 1 995 4:51 PM 

To: tbr 

Cc: pmayer 

Subject: Re: Bad board news 



> From tbr Wed Aug 2 23:59:42 1995 

> To: pmayer (Patricia Mayer) 

> Subject: Bad board news 



> Patricia Mayer wrote (on Wed Aug 2) : 

> Tim, 

> I'm sorry to say that I have discovered incorrect DRC settings on several 

> boards . 

> I've been working on the Allegro Design Guidelines for the past week, recording 

> all I've learned about schematics and responding to question Ngau has had that 

> weren't answered in the Guidelines. 

> Great you are adding that stuff . 

My plan is to have this complete by Monday when Ngau returns. Then I'll have a meeting 
with the layout designers and review it all. I'll copy you on the mail. 



> X decided to test my DRC constraints on an "approved" board. I chose Euterpe. 

> Much to my dismay, the DRC's were set to 5 mil spacing and the layout grid was 

> set to 1 mil. This is a formula for errors! Our design rule is 6/6 and absolute 

> minimum is 5/5. As we know its not nice to push manufacturing. I don't know 

> how the circuit will react to 6/5... The rule was set by Bill Herndon who 

> emulated 6/6 (I think?) and I'm not sure if this was only for the diferential 

> pairs only. 

> 6 6 I think pretty much came form the 11 . 8 mil spacing of the pad 

> ring. The 100 ohm requirement was then satisfied by specifying the 

> dielectric thickness I think. I think bill was mainly looking at the 

> differential pairs because on the digital boards these are really the 

> only things that need controlled impedance. 

Ah, I do remember that Brian had requested Bill review something using these numbers and 
because 6/6 was the rule for these lines it became the standard. However, because of the 
tab, 7 mil pads spaced at 11.8, the pin to pin rule is 4.8, line to pin is 5.3 and line to 
line is 5.8. The TAB area is the exception to the rule but DRC's are global across the 
board in Allegro. 

If, however, a 6 mil grid is used, the rest is easy (easier said!). 

I don't have any understanding why the grid wasn't utilized and respected. 



> Anyway, after I reset the rules there were 171 errors! Of course the design 

> summary we reviewed during our meetings was based on the erroneous setting so 

> it looked great. 

> How big a deal is it to edit these to correct them? 

I'd estimate at least a two weeks per board (except Herminatior) . After the traces and via 
locations are fixed, the inner layer shapes need to be re-generated (drc was also set to - 
5) along with the drill and supporting documents. 
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> This also effects the Euterpe XRAM which might be easier to re-do once, the 

> Euterpe module is fixed. 

> The Mnemo module had 229 errors. This will need editing for the new pinout 

> anyway. 

> Are they mostly in the DRAM area, or on the hermes channel? 

I'm seeing about 100 of the errors are around the DRAMs where we do have 5/5 
routing between the surface mount pads. The rest is random expecially in 
areas densly populated with 45 degree lines. These areas, of course, have a 
lower spacing then the parallel lines. 



> And the Herminator has 24 errors. These are just spacing for the vias to 

> provide inner layer, gnd and vdde, coverage between the vias. 
> 

> Does this mean we get close to slots again? 

Yes, and that wasn't caught at a review either. 1 don't think its a big deal 
on the herminator but I don't see why we shouldn't fix it. 



> I'm sure all of this is fix-able. 

> Can you assess the effort required so we can decide priorities? Based 

> on today's meeting it's clear we have to have Euterpe and Cronus as 

> the top priorities, though I think our current scheduling says we have 

> these in time even with the other things going on. Jay is going to 

> shift focus from the bridge to Cronus for a while. 

Great. Jay did stop by and mentioned he had a ring pinout and he would start 
working on the schematics since Ngau is out and I'm working on the Euterpe 
bare die test board {MMS membrane on the round card) . I would think thats 
the next highest . priority in line and I thought I'd make time to reroute 
the Pandora Euterpe. 

Howard is working on the Euterpe Yamaichi socket for testing the TAB device 
and Mnemo. I need to verify the constraints are in place for the boards. 
Ngau has the ISA, Backplane and Bridge. Perhaps when she gets back, she 
can pick up on the Euterpe and definitly the Euterpe XRAM. 



> In the long term, I have already added a copy of the DRC Constraint form to 

> the guidelines. As a matter of fact, thats what I was testing when I discovered this. 
I've also added a reguirment to print the DRC constraint settings for 

> the design reviews along with the Summary report currently brought to the 

> review. 
> 

> That's a good idea. How are the DRC's run and how is the ruleset 

> selected? Is there any way to automate this (eg with Makefiles) so 

> we can guarantee to get the standard flows from a shared place? 

The ruleset is selected based on the smallest rules and they are on-line 
updates. The designer is responsible for turning the graphics on and there 
is an 'update DRC command to verify the current statistics. 
For areas like the DRAM, I was planning a "before" where the DRC's are set 
to 5.8/6 and then "after" where the DRC's are set to 5/6. This will give us 
an accurate understanding of the DRAM area and DRC's waivable. This actually 
might have been why the DRC's were set to 5 spacing but combined with the 
inaccurate grid setting of 1 mil, its fatal. 

Good automation suggestion (must be why your the boss making the big bucks) . 
I created a macro but that still requires the layout designers remember to 
'run' the damn thing. (I'm resisting "having an attitude", on this but I'm 
very disappointed and on occasion can't help myself.) 



In the short term, I need to ask Howard to put in more hours. He's been really 
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> good at putting in his 4 0 (hourly minded) but I need to reitterate your offer 

> statement that this is a salery position at a startup. We expect the hours. 

> I think in view of things said at the meeting today this would be just 

> the right time to raise that. 

Howard seemed to think "extra hours" would be OK. It seems as though he sees 
the re-pinout as the problem.? 



> I'm really sorry about this, and I'm glad I caught it now.. Also in the future 

> I will be reviewing the data on-line to mark the check list. 

> Better now than later. Again if there is any opportunity to automate 

> to remove manual steps that could be subject to error let's look at it. 

> Do you have any further thoughts or suggestions? 

> Given this surprise I'm wondering how fine we should cut things in 

> getting first versions of the boards fabed. We have fairly 

> conservative numbers in the schedule for fab and assembly, but given 

> the possibility of something of this seriousness not being picked up 

> till Hadco are looking at the artwork (and I guess based on past 

> experience there has always been some issue) ; we may want to look at 

> sending them out earlier. 

I really think this is a GREAT idea. I'll work with Philip to prepair an 
evaluation package for manufacturing as soon as we are done. An evaluation 
may even be free!? 



I'll update the schedule and have that out by the end of the day. 
I suppose I need to take this to the Pandora meeting. 

Thanks Tim, 
Pattie 
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From: jack (Jack Wenstrand) 

Sent: Thursday, August 03, 1995 1 :34 PM 

To: at geert; paulp; hopper; vanthof; torn; anh; Jack; rich; ong 

Cc: mouss : ton y: manser; wingard; mudge; cadettes; fung; kumar; tomb; yao; rip; to; ted" ky lianq- 

_ . , . f,°? v; li ; ancy; linden; anderson ; alves : graham; dane; yves; ras; tomho; michael; solo; tbr; tony 

Subject: Notes, layout review, 8/4/95 * 



Euterpe pad 
Issues: 

1) SDEC fill is a show stopper. The fab is concerned 
that unless substantial progress is made with 
increasing the amount of SDEC on the die, we will be 
unable to yield anything. In particular, this 
causes emitter-base shorts. The design community is 
concerned that to fully implement the increase in 
SDEC would require a major change in methodology and 
months to implement. 

* Action: Al will see Dave V. to identify the best 
course of action consistent with the Euterpe goal, 
and present an update at the 8/4 layout review. 

2) Pad metal. 

Use long parallel lines. Ml should run 
perpendicular to SDEC. 

) Pad capacitance . 

Put the pad over a reverse-biased n-well to reduce 
pad capacitance. Turn off the buried layer 
requirement here to prevent autodoping. 

* Action: Geert to make this happen, and coordinate 

with Paul. 

4) Protection diode. 

Change metal to distribute Current over diode. 
Center contact pedestal over SDEC. Ballast 
resistors might be necessary. 

* Action: Johnny: Work on this, check with Al, feed 

results back to Paul for integration. 

5) Comb structure. 

* Action: Paul: kill it. 

Wait list: 

6) The power bus is too small. 

7) Long contact pedestals occur throughout Euterpe and 
may not makable. 



Next meeting: Today, Thursday, 3pm, Multimedia Room. 
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From: 



tbr 

Thursday, August 03, 1995 2:00 AM 
pmayer (Patricia Mayer) 
pmayer 

Bad board news 



Sent: 

To: 

Cc: 



Subject: 



Patricia Mayer wrote (on Wed Aug 2) : 



Tim, 



I'm sorry to say that I have discovered incorrect DRC settings on several 
boards . 

I've been working on the Allegro Design Guidelines for the past week, recording 
all I've learned about schematics and responding to question Ngau has had that . 
weren't answered in the Guidelines. 

Great you are adding that stuff . 

I decided to test my DRC constraints on an "approved" board. I chose Euterpe. 
Much to my dismay, the DRC's were set to 5 mil spacing and the layout grid was 
set to 1 mil. This is a formula for errors! Our design rule is 6/6 and absolute 
minimum is 5/5. As we know its not nice to push manufacturing. I don't know 
how the circuit will react to 6/5... The rule was set by Bill Herndon who 
emulated 6/6 (I think?) and I'm not sure if this was only for the diferential 
pairs only. 

6 6 1 think pretty much came form the 11.8 mil spacing of the pad ring. The 100 ohm 
retirement was then satisfied by specifying the dielectric thickness I think. I think 
bill was mainly looking at the differential pairs because on the digital boards these are 
really the only things that need controlled impedance. 

Anyway, after I reset the rules there were 171 errors! Of course the design 
summary we reviewed during our meetings was based on the erroneous setting so 
it looked great. 

How big a deal is it to edit these to correct them? 

This also effects the Euterpe XRAM which might be easier to re-do once the 
Euterpe module is fixed. 

The Mnemo module had 229 errors. This will need editing for the new pinout 
. anyway. 

Are they mostly in the DRAM area, or on the hermes channel? 

And the Herminator has 24 errors. These are just spacing for the vias to 
provide inner layer, gnd and vdde, coverage between the vias. 

Does this mean we get close to slots again? 

I'm sure all of this is fix-able. 

Can you assess the effort required so we can decide priorities? Based on today's meeting 
it's clear we have to have Euterpe and Cronus as the top priorities, though I think our 
current scheduling says we have these in time even with the other things going on. Jay is 
going to shift focus from the bridge to Cronus for a while. 

In the long term, I have already added a copy of the DRC Constraint form to 
the guidelines. As a matter of fact, thats what I was testing when I discovered this. 
I've also added a requirment to print the DRC constraint settings for 
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£evieJ Si9n rSVieWS along with the Summary report currently brought to the 
That's a good idea. How are the DRC's run and how is the mlPdPt- opu^^, T . , 

^ h \ Sh °^- te ^' 5- neSd t0 ask HoWard to put in more hou ^s- He's been really 

s?2emenrtJa? 9 tnL is 40 bUt 1 need t0 iterate your 3?« 

statement that this is a salery position at a startup. We expect the hours. 

raiie n tha?. VieW ° f tMngS at the meStinS t0day this would be ^ust the right time to 

SSTtS co^Sf - ™ ^ e manual 

Do you have any further thoughts or suggestions? 

always been some issue) , we may want to look at sending them out eXier 
Tim 
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From: 



pmayer (Patricia Mayer) 
Thursday, August 03, 1995 1:44 AM 
tbr 

pmayer 

Bad board news 



Sent: 
To: 
Cc: 



Subject: 



Tim, 



I'm sorry to say that I have discovered incorrect DRC settings on several boards. 

I've been working on the Allegro Design Guidelines for the past week, recording all I've 
learned about schematics and responding to question Ngau has had that weren't answered in 
the Guidelines. 

I decided to test my DRC constraints on an "approved" board. I chose Euterpe. 
Much to my dismay, the DRC's were set to 5 mil spacing and the layout grid was set to 1 
mil. This is a formula for errors! Our design rule is 6/6 and absolute minimum is 5/5. As 
we know its not nice to push manufacturing. I don't know how the circuit will react to 
6/5... The rule was set by Bill Herndon who emulated 6/6 (I think?) and I'm not sure if 
this was only for the dif erential pairs only. 

Anyway, after I reset the rules there were 171 errors ! Of course the design summary we 
reviewed during our meetings was based on the erroneous setting so it looked great. 

This also effects the Euterpe XRAM which might be easier to re-do once the Euterpe module 
is fixed. 

The Mnemo module had 229 errors. This will need editing for the new pinout anyway. 

And the Herminator has 24 errors. These are just spacing for the vias to provide inner 
layer, gnd and vdde, coverage between the vias. 

I'm sure all of this is fix-able. 

In the long term, I have already added a copy of the DRC Constraint form to the 
guidelines. As a matter of fact, thats what I was testing when I discovered this. I've 
also added a requirment to print the DRC constraint settings for the design reviews along 
with the Summary report currently brought to the review. 

In the short term, I need to ask Howard to put in more hours. He's been really good at 
putting in his 40 (hourly minded) but I need to reitterate your offer statement that this 
is a salery position at a startup. We expect the hours. 

I'm really sorry about this, and I'm glad I caught it now. Also in the future I will be 
reviewing the data on-line to mark the check list. 

Do you have any further thoughts or suggestions? 
-Pattie 
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: rom: vanthof (vant) 

Sent: Wednesday, August 02, 1995 4:12 PM 

X o: Seert (Geert Rosseel); tbr (Tim B. Robinson); iisar (Lisa Robinson); hopper (Mark Hofmann) 

Cc: vanthof (Dave Van'tHof); torn (Tom Laidig) 

Subject: fullchip drc run still going 



I have severely underestimated the time it takes to do a fullchip drc run. 
This is the first time a fullchip has been run with the new drc flow which does a 
significant amount of post processing to emulate tapeout. This process added quite a bit 
of time, more than I thought. I had estimated that a lower fullchip drc would take 2 
days, and it's probably closer to 

4 or 5 days, I'm unsure of just how long it really will be. 
Dave 



Dave Van't Hof MicroUnity Systems Eng., Inc. 255 Caspian Sunnyvale, CA 94089 
vanthof@microunity.com 1 408 734-8100 

"I don't know the meaning of the word surrender! I mean, I know it, I'm not dumb... just 
not in this context . " The Tick to Thrackazog 
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From: 
Sent: 
To: 
Cc: 



tbr 

Tuesday, August 01, 1995 8:32 PM 
Daniel Albers 

albers@microunity.com; geert@microunity.com; hopper@microunity.com; 

tau@micrountty.com; tom@microunity.com; vanthof@microunity.com; 

wampler@microunity.com 

Re: euterpe tapout? here we go... 



( 



Subject: 



Daniel Albers wrote (< 



Tue Aug 1) : 



Let's break the idea of the frame up into 2 parts: 



1) Frame scribeline data 

The frame can always be re-used provided we don't want to change any 
cells inside of it. We did plan on using different etest cells in 
the pollux and euterpe reticle sets. 



2) Device/scribe interface (1 um ring surrounding each device 
placed in the frame) . 

The device/scribe interface ring will almost always need to be . 
regenerated unless we are positive that the die -edge is 
identical between tapeouts. 

On pollux the cell f 0011_ring.ly would just be regenerated and 
checked- in. This takes a couple of hours pollux. Probably the 
same for euterpe. 



Daniel Albers albersOmicrounity , com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, ' CA (408) 734-8100 



"Evil is just plain bad! You don't cotton to it. You gotta smack it in the 
nose with the rolled-up newspaper of goodness! Bad dog! Bad dog!" 

- The Tick. 



Thanks for the clarification. 



Tim 
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r rom: Daniel Albers [albers@microunity.com] 

Sent: Tuesday, August 01 , 1995 4:35 PM 

To: tim B. Robinson 

Cc: albers@microunity.com; geert@microunity.com; hopper@microunity.com; 

tau@microunity.com; tom@microunity.com; vanthof@microunity.com; 

wampler@microunity.com 
Subject: Re: euterpe tapout? here we go... 

> the words of Tim B. Robinson: 

> Daniel Albers wrote (on Tue Aug 1) : 

> Primarily we put in different etest cells in the frame. 

> So if really pressed could we re-use a frame for a different tapeout? 



Let's break the idea of the frame up into 2 parts: 

1) Frame scribeline data 

The frame can always be re-used provided we don>t want to change any 
cells inside of it. We did plan on using different etest cells in 
the pollux and euterpe reticle sets. 

2) Device/scribe interface (1 um ring -surrounding each device 
placed in the frame) . 

The device/scribe interface ring will almost always need to be 
regenerated unless we are positive that the die-edge is 
identical between tapeouts. 

On pollux the cell f 00ll_ring. ly would just be regenerated and 
checked-in. This takes a couple of hours pollux. Probably the 
same for euterpe. 



Daniel Albers albers@microunity.com MicroTJnity Systems Engineering, Inc 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 

"Evil is just plain bad! You don't cotton to it. You gotta smack it in the 
nose with the rolled- up newspaper of goodness! Bad dog! Bad dog!" 
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From: tbr 

Sent: Tuesday, August 01 , 1 995 2:22 PM 

To: Daniel Albers 

Cc: albers@microunity.com; geert@microunity.com; hopper@microunity.com; 

tau@micrountty.com; tom@microunity.com; vanthof@microunity.com; 

wampler@mtcrounity.com 
Subject: Re: euterpe tapout? here we go... 



Daniel Albers wrote (on Tue Aug 1) : 

Primarily we put in different etest cells in the frame. 
So if really pressed could we re-use a frame for a different tapeout? 
Tim 
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-rom: torn (Tom Laidig [tau}) 

Sent: Tuesday, August 01, 1995 11:02 AM 

To: KurtWampler 

Cc: a,be ^ (Daniel Albers); geert (Geert Rosseel); hopper (Mark Hofmann); tbr (Tim B. Robinson)- 
vanthof (Dave Van't Hot); tau ; " 

Subject: Re: euterpe tapout? here we go... 

Kurt Wampler writes .- 
Tom writes: 



>I just got buttonholed by Jack, Al, and Anh for an impromptu meeting 
>about euterpe tapeout, given the edict that we must have euterpe 
>silicon by Dec 31. I explained that euterpe, as it exists now, does 
>not meet the "compromise' design rule set developed last week, and I 
>estimated 3 months of layout work before it could be made to do so. 

Not to mention the very real risk that Euterpe would no longer route 
to completion with the compromise rules' larger vias. 

Y l^' 1 ™? ntio * ed th ?t as well- Also the fact that we'd lose some rows of atoms and a few 
other things by trying to meet the other provisions of the compromise rules. 

>Given this, Al and Anh agreed that the best move is to tape out the 
>baseplate layers (currently defined as 010-140 -- all but metals, 
>SDEC, and silicide) ASAP in their current form, and pressed me for an 
>estimate of how soon this could happen. I made the' possibly rash 
statement that I thought we might be able to tapeout the baseplate on 
!>Aug 14. (Jack mentioned some 1- or 2-udr well-well and well-nactive 
>spacing violations, to which Al said "waive them') 

Will there be any changes needed on the poly layer to comply with 
the new SDEC ISO rules? 

No; we are not going to meet the new SDEC ISO rules. We can dink with SDEC as much as 
seems good to improve our situation vis-a-vis the SDEC ISO rules, but we don't really have 
any time to do this, so I don't anticipate any real progress. 

>After some argument, we settled on Sep 1 as the target date to tape 
>out the layers up through Ml (plus any more metals we can get out by 
>then) , with the remaining metal layers taping out promptly thereafter. 

This is "ship physical tapes on Sep 1" or "commence fracture on Sep 1"? 

I don't see a problem with shipping tapes on Sep 1 as long as we 
start the fracture by Aug. 28. We'll need 2-3 days to compute layers 
010-140, and a little time to review post-fracture DRC flags & write 
the tapes. 

The quoted dates are actual tape ship dates -- ie, we must ship the tapes for 010-140 by 
6pm on Aug 14; 150-180 by 6pm on Sep 1. It sounds as if this means we start the 010-140 
fracture on Aug 11 at the latest. 

The other metals are of less immediate interest to the fab (they need 

Ml to get transistor characterization, which is why that date is spec'ed), but the 

implicit assumption is that we'll ship the other metals within a week or thereabouts. 

>~'_ 
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From: Daniel Albers [albers@microunity.com] 

Sent: Tuesday, August 01, 1995 10:27 AM 

To: Tim B. Robinson 

Cc: albers@microunity.com; geert@microunity.com; hopper@microunity.com; 

tau@microunity.com; tom@microunity.com; vanthof@microunity.com; 

wampler@microunity.com 
Subject: Re: euterpe tapout? here we go... 

> the words of Tim B. Robinson: 

> Daniel Albers wrote (on Mon Jul 31) : 

> > the words of Tom Laidig [tau] : 

> > [snip] 

> > I hope I didn't commit (however tentatively I tried to do so) to 

> > anything _too_^ rash. My estimates were predicated on a lot of stuff I 

> > don't know enough about, including, but surely not limited to: 

> > There's a frame that is ready, or very nearly so 

> > [snippitte, snip, snip] 

> The frame is "nearly" ready. The one that is check 'd in is completely 

> wrong. But I believe I can have a good frame put together by the guestimated 

> tapeout dates ... 
> 

> Why does the frame need to be any different from the one (I assume) we 

> have ready for pollux? 



Primarily we put in different etest cells in the frame. 
Dan 



Daniel Albers albers@microunity.com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 

"Evil is just plain bad! You don't cotton to it. You gotta smack it in the 
nose with the rolled-up newspaper of goodness! Bad dog! Bad dog!" 
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From: 



wampler (Kurt Wampler) 
Tuesday, August 01, 1995 12:27 AM 
albers; geert; hopper; tbr; torn; vanthof 
tau 

Re: euterpe tapout? here we go... 



Sent: 
To: 
Cc: 



Subject- 



Tom writes: 



>I 3 ust got buttonholed by Jack, Al, and Ann for an impromptu meeting 
>about euterpe tapeout, given the edict that we must have euterpe 
>silicon by Dec 31. I explained that euterpe, as it exists now, does 
>not meet the "compromise' design rule set developed last week, and I 
>estimated 3 months of layout work before it could be made to do so. 

Not to mention the very real risk that Euterpe would no longer route 
to completion with the compromise rules' larger vias. 

>Given this, Al and Anh agreed that the best move is to tape out the 
>baseplate layers (currently defined as 010-140 -- all but metals, SDEC 
>and silicide) ASAP in their current form, and pressed me for an 
>estimate of how soon this could happen. I made the possibly rash 
statement that I thought we might be able to tapeout the baseplate on 
>Aug 14. (Jack mentioned some 1- or 2-udr well-well and well-nactive 
>spacing violations, to which Al said "waive them') 

Will there be any changes needed on the poly layer to comply with 
the new SDEC ISO rules? 

^After some argument, we settled on Sep 1 as the target date to tape out 
the layers up through Ml (plus any more metals we can get out by then) , 
>with the remaining metal layers taping out promptly thereafter. 

This is "ship physical tapes on Sep 1" or "commence fracture on Sep 1"? 
I don • t see a problem with shipping tapes on Sep 1 as long as we 
start the fracture by Aug. 28. We'll need 2-3 days to compute layers 
010-140, and a little time to review post-fracture DRC flags & write 

t.Y\e> t-anso 



>The impression I have now is that taping out euterpe is our highest 
>priority, but I dunno -- the highest priority seems to change several 
>times a week as far as I can tell. 

Whether we tape out euterpe, pollux, or mnemo, the drill is pretty 
similar, and once we've ironed out all of the synthesis details 
for one of them, the others ought to follow pretty much the same 
formula (except for any midstream revisions we make in response to 
Sisyphus 2 characterization) . 

>Are we having fun yet? 

Can't wait to get ported onto that Alpha box! 



the tapes. 



> [snip] 



- Kurt 
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Sent: 

To: 

Cc: 



Subject: 



From: 



tbr 

Tuesday, August 01, 1995 12:17 AM 
vanthof (vant) 

albers {Daniel Albers); geert (Geert Rosseel); hopper (Mark Hofmann); Tom Laidig [tau]; 
vanthof (Dave Van't Hof); wampler (Kurt Wampler) 
Re: euterpe tapout? here we go... 



vant wrote (on Mon Jul 31) : 



. >After some argument, we settled on Sep 1 as the target date to tape out 
>the layers up through Ml (plus any more metals we can get out by then) , 
>with the remaining metal layers taping out promptly thereafter. 

According to what rules? If we are going to tape out euterpe to the 
current rule set, then I think we can do upto metall. if we are to meet 
the compromised set, then your estimate of 3 months is more accurate. 

Plan should be to get it clean per the current rules and get going with that version so we 
have the soonest possible mask set. It may make sense to follow that up with a revised 
version which also meets a subset of the compromise rules if we can get some guidance on 
the most important. . ie do the 10% of the work that gets the 90% benefit. 



Tim 
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